Forums Register Login

Practical use of multiple object references pointing to same object

(1 cow)
+Pie Number of slices to send: Send
Hello all, thanks in advance for the clarification!
Currently I am on day 3 of learning how to program (I dabbled a little in Basic on my dad's old Sperry, but I don't count that). I am reading Head First: Java and got to Object References. In the book I got a little bit confused on what happens when two object reference's point at the same object so I wrote a small crude test, the below code. This of course clarified what happens but what I am interested in knowing is in what circumstances would you want to have two separate references for the same object when you could just use the original? Eg. v1
+Pie Number of slices to send: Send
Hello Alex, welcome to the Ranch!

I dabbled a little in Basic on my dad's old Sperry


Wow! That was a long time ago. My dad worked for Burroughs, which was the company Sperry merged with to become Unisys back in the 80's.

You are exploring a part of Java that causes a lot of people trouble, and it's something that's certainly burned me on more than one occasion too. In your example, there's not really much point in creating v2 but it becomes less clear when passing references in and out of classes and methods. Take this example:

The point of this demonstration is that the List being returned from getNames() is always the same List. Meaning that any modification made to that List is observed by all clients of Names that have obtained the List through getNames(). This is not the natural behaviour you would expect and can be the cause of some very weird bugs in applications (believe me, I've lived through the pain of those types of bugs).

In my particular example, the way to avoid this confusion is to have getNames() return a copy of the List object rather than the List itself.
+Pie Number of slices to send: Send
Thanks for taking the time Tim! My dad and a few extended family members worked for Unisys for a while.

I can see why returning a copy would be best in your example. From my example (as far as I understand) it shows that v2 doesn't return a copy of v1's state when assigned, it just points v2 to the same object. Otherwise v2 would have printed 1 instead of 3. Am I missing something, or is it because of the way I attempted to copy v1?
+Pie Number of slices to send: Send
Yup, you got it. Here's a small CodeRanch article that explains it quite well --> CallByReferenceVsCallByValue
+Pie Number of slices to send: Send
 

Alex Hintz wrote: what I am interested in knowing is in what circumstances would you want to have two separate references for the same object when you could just use the original? Eg. v1



So I take it that there isn't really a practical use for using two references for the same object then (cause's more problems without solving any).
2
+Pie Number of slices to send: Send
There are applications where multiple references to a single object is desirable. In these cases you tend to find a deliberate implementation of the Singleton Pattern.

One example would be database access where the database can only handle a single thread connection. In this case you have a single object that does the connecting to the database, and then different parts of your application would hold multiple references to that object.

There are other examples of course, but for general purpose programming I would advise against such sharing as in my experience it tends to create more problems than it solves. For further reading around this topic I would suggest you do some internet searching for "mutable state" and "immutable state", which will almost certainly have you reading articles about Functional Programming which will do you no harm whatsoever.

Now, with my CodeRanch Moderator hat on, I'd like to give Kudos on two counts:
- Firstly, for taking the time to figure out how to UseCodeTags for posting your code example. It makes it so much easier to read.
- Secondly, for having the initiative to explore the thing you didn't understand with a good dose of test code before asking for help.

I think that deserves a cow.
+Pie Number of slices to send: Send
 

Tim Cooke wrote:There are applications where multiple references to a single object is desirable. In these cases you tend to find a deliberate implementation of the Singleton Pattern....


Have to disagree with Tim here. However, I think he and I probably agree why you might want to point to the same object.

@Alex - Some objects (in fact, most of mine) are immutable. The classic case is "Hello World", which is a Java String.

You can't change it, and you can only add to it by creating a new String. So: why should one instance of "Hello World" be different to any other?

Answer: None. And therefore they ARE the same object - as you'll soon find out when you use the "==" operator on them (but don't make it a habit).

But what about a Book? There are millions of those, and I might want to create a Library class that contains thousands of them. And then it's not so simple.

I might have two Books called "Moby Dick", and be pretty sure they're probably the same book. But what if they're "The Bible"?
There are dozens of versions of the Bible - even if you discount pre-King James' versions, or ones written in Latin - is a Gideon Bible the same as the New American version? And are either of those the same as the KJ?

NO.

You have two Book objects that look that same, but are NOT the same Book. And darn it, someone called Winston might even decide to write a book called "Moby Dick", so wouldn't it be better to check if the author was Herman Melville before you decide whether two Books called "Moby Dick" are actually the same ones?

And that's what the equals() method is all about. It tells you whether two objects are "equal" - not identical (ie, the same object) - and you get to define that any way you like.

And believe me, it's usually MUCH more important to know whether two objects are "equal" than whether they're the same object. So, while I can't fault Tim's statement, I'd say that the chances of it being important to point to two identical objects are very slight.

Have a look at the AvoidTheEqualityOperator (←click) page for more details.

HIH

Winston
1
+Pie Number of slices to send: Send
a doublelinked list may be a concrete example where you have multiple references to the same object. Both node 1 and node 3 would have a reference to node 2. you may also have a "head" and "tail" reference pointing to the...well..head and tail of the list.
+Pie Number of slices to send: Send
 

fred rosenberger wrote:a doublelinked list may be a concrete example where you have multiple references to the same object. Both node 1 and node 3 would have a reference to node 2. you may also have a "head" and "tail" reference pointing to the...well..head and tail of the list.


And in such a situation they are the same (Node) object, because it refers to a position in a structure (a linked list), but it is very rare for two pieces of data to be identical merely because they are similar - indeed, that's why we have an equals() method. YOU decide when data are "equal".

Winston
+Pie Number of slices to send: Send
Thanks for the time and insight guys. It seems like I have a lot more reading/tinkering ahead of me.
Poop goes in a willow feeder. Wipe with this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 4260 times.
Similar Threads
Basic reference question
Confusing Integer.max() method
parameterpassing
arrayOutOfIndex
Shallow Copying And Deep copying ?
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
Shallow Copying and Deep Copying
JavaCaps Test 2, Question # 33
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 12:16:49.