File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes Objects returned by normal get*() methods: references or copies ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Objects returned by normal get*() methods: references or copies ?" Watch "Objects returned by normal get*() methods: references or copies ?" New topic
Author

Objects returned by normal get*() methods: references or copies ?

James Adams
Ranch Hand

Joined: Sep 12, 2003
Posts: 188
Let's say I have the following class:

public class MyClass
{
// member variable
private HashMap m_map;

// getter method
public HashMap getMap ()
{
return m_map;
}

// 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 ?

Thanks in advance...


--James
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

You've written the getter as



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.


[Jess in Action][AskingGoodQuestions]
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Just to be clear, even if we implement the method to return a clone, we're actually returning a reference to the clone we've created. We're not returning the object itself.

For details on references and cloning, see Bruce Eckel's "Passing and Returning Objects" appendix in Thinking in Java...

http://www.faqs.org/docs/think_java/TIJ319.htm


"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
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.

Layne


Java API Documentation
The Java Tutorial
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Objects returned by normal get*() methods: references or copies ?