3

Would it be overhead to always return a copy of collection/object field?

Alexey Galanov
  • 421
  • 4
  • 21
  • Sorry, but "would it be overhead" clearly goes into the "give me your opinions" ballpark. In that sense, your question doesn't fit here. My opinion: it really depends. If your design works better if you return copies, then do that. If it is important that all parties are dealing with the **same** objects, then maybe you don't create clones. – GhostCat Jul 15 '16 at 10:35
  • Semi-related: http://stackoverflow.com/questions/19192762/inefficiency-of-defensive-copy-in-java – jaco0646 Jul 15 '16 at 15:58

2 Answers2

3

Clearly, yes it would be a overhead ... compared with returning a reference or a shallow copy.

But that's not really the point. The real point is whether the overhead is warranted / necessary, and whether it can be avoided by using some other data structure / design / technique. The answer to those questions depends on the context.

Here are some illustrations:

  1. If a target object getter returns an immutable object, a copy is unnecessary. Example, any getter that returns a String.
  2. If a target object getter returns an object that is not part of the target object abstraction, a copy is undesirable. Example list.get(int), Iterator.next().
  3. If a target object getter returns a mutable object (or array) AND the returned object is part of the object's internal state AND the target doesn't necessarily trust the caller, then the getter should either copy it or wrap it ... or there may be a security problem.
  4. The same may apply in non-security-related contexts; e.g. ArrayList.toArray(...) copies the list into an separate array rather than returning the list's backing array. (Similar for getChars() for a String, StringBuffer, etc.) This is all about maintaining the abstraction boundary so that on class won't "break" another one.
  5. If a target object getter returns a mutable object (or array) AND the returned object is part of the object's internal state BUT the target object's API / abstraction boundary is designed to be "porous" (e.g. for performance reasons), then copying may be self defeating.

Of these, 3 is the only case where cloning is strictly mandatory. In 2, 4 and 5 you could argue that it is a matter of how you design the public (or internal) APIs for the classes, libraries, applications. And often there are many viable choices.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • @StephenC It would be really great if you could give some examples when it's necessary to clone objects in getters of mutable objects – Alexey Galanov Jul 15 '16 at 11:26
1

It is overhead for sure but there are already some framework classes which do that. It is also described in the book Effective Java.

Remember:

"Classes should be immutable unless there's a very good reason to make them mutable....If a class cannot be made immutable, limit its mutability as much as possible."

When you want to create immutable classes than you can use a framework like that: http://immutables.github.io

For examples check this Oracle documentation

wake-0
  • 3,918
  • 5
  • 28
  • 45