In my opinion, this is almost always both undesirable and easily avoidable. There is a huge difference in beeing able to query (even efficiently) for related objects, and litter direct references all about and in both directions. Most you get out of going down that road is a huge pain trying to assess correctness.

I'm familiar with the kind of c++ pointer design you mention, and in C++ you will sometimes need them, but most often I think one should be able to do without if one otherwise arrange things so that you tell your objects to act upon input, in stead of doing things to them directly.

But, there is so many design considerations I have not participated in or fully understood, so I am interested in seeing cases where it might make sense.

The compelling case that made me think through how to do it right, rather than avoid it on a case-by-case basis, was in GUI windowing. A window contains a list of its children, and the child points back to its parent. Meanwhile, I was working on asynchronous programming concepts. A "weak reference" can't work if the order of destruction is not defined. This concerned writing the functions that do the acting on input! Basically, WNDPROC in Windows, or closures binding an object and method to call queued to a server thread. When a method is being executed, the object cannot be destroyed. But between, it is fair game, and pending things will fail (guaranteed) as the graph of objects is being taken apart. Basically, think of your query idea as "reference" without using the problematic pointer. I separated the concepts of "reference" from "ownership". Without prompt destruction like I like and depend on in C++, the latter concept might be better described as "dependency".

I agree that most relationships are not explicit because objects act on input rather than being known by each other. But I have small knots of typically 2 objects in this relationship, and the ability to separate the lookup from the use in time due to asynchronous calling.

—John