This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
// more methods to add/remove HashMap elements, etc. }
If I call the getMap() method on an object of this class then do I get a copy of the object's HashMap member variable, or do I get a reference to it ? If I get a reference then any subsequent modifications made to the returned HashMap will effect the state of the MyClass object's internal HashMap member variable, whereas if I get a copy then the original MyClass object's member HashMap is safe. Therefore I assume that the value returned is actually a copy and not a reference, is this correct ?
and therefore a reference to the exact same HashMap object is returned. You could, alternatively, write something like
and return a copy instead, if you so chose. But as far as Java goes, what you see is what you get; Java never, ever magically copies an object behind your back.
Now, as far as design issues go: handing out references to a mutable private member is often a Bad Idea. There are a number of alternatives. One is to return a copy, of course. Another is to return a read-only iterator. A third is to write delegating methods like
which basically allow read-only access to the data without exposing the implementation.
Marc makes a good point. In Java we ALWAYS manipulate references to objects, not the objects themselves. When you understand this, hopefully it will help you generalize the concept that you've encountered here in order to see how it works in other contexts.