My two cents:
We always prefer to teach that objects all stand alone in the heap, but that they might have reference variables that provide a way of hooking them together. There are several reasons why this might be a better visualization:
1 - It allows for the case where two or more objects 'have' or 'refer to' another single object. In this case, if two objects refer to the same object, in which of the two referers would you say the refer-ee lives?
2 - It makes thinking about garbage collection easier. If you use the analogy that an object contains another object, then what happens when you null the referers reference? Does the refer-ee object get 'kicked out'? (if so, where does it get kicked out to?) Also, this ties back to the first point, if you've just 'kicked out' an object, what if another object still has a reference? How does this effect the object's eligibility for the garbage collector?
3 - What happens when you lose your reference to the referring object? Does that mean you've lost the refer-ee object? Not if another object also referred to the refer-ee object.
So, once again, we recommend that you visualize objects as standing alone in the heap, with lots of links to each other.
Oh, here's another thing, when you start thinking about inheritance, we often find that it might be useful to imagine that when you make, say a Dog object, there's a little, inherited Object object inside the Dog object... so we'd really hate to overload our visual metaphors
hth,
Bert