• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 11343
Mac Safari Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
If you settle for what they are giving you, you deserve what you get. Fight for this tiny ad!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic