Are there any guiding principles of OO design to take into account when deciding which of two interacting and linked objects should be included as a component into the other (or referenced from it)?

For example, I am trying to realise the A* shortest path search algorithm with classes and objects. Besides a given graph, I plan to have a DataFlow object and a Controller object. I plan the DataFlow object to be responsible for maintaining the state of knowledge about the shortest paths found so far and for propagating improvements from nodes to their neighbours. I plan the Controller object to be responsible for the graph exploration strategy and to make it configurable with any of a number of strategies (A*, Dijkstra, greedy, etc.).

After some thought, I've decided that the DataFlow object is going to receive and store the Controller object during initialisation, but I cannot explain clearly why this would be better than the other way around.

  • 2
    Perhaps you can start by choosing names that better reflect responsibilities, such as ShortestPaths' and PathFinder` (or `ExplorationStrategy').
    – Marco
    Feb 25, 2019 at 14:53
  • How are these objects interacting? That would seem to be the most important thing here.
    – JimmyJames
    Feb 25, 2019 at 14:56
  • @Marco, IMO my names reflect the responsibilities better (the Controller is more than a strategy, the DataFlow object does not manipulate paths, etc.) The choice of names is in any case irrelevant.
    – Alexey
    Feb 25, 2019 at 14:57
  • @JimmyJames, they will obviously interact slightly differently depending on which one will be calling methods of the other. DataFlow does not care where to go next and which updated node to treat next by updating its neighbours. Controller keeps only as much information as necessary to be able to tell the DataFlow where to go next. So, the Controller controls the DataFlow, but it can either send messages and receive, or receive and send.
    – Alexey
    Feb 25, 2019 at 15:04
  • 2
    "The choice of names is in any case irrelevant" - absolutely disagree. If you have a clear understanding of responsibilities, good names often follow naturally. Conversely, un-informative names like "Controller" frequently betray confused thinking about the named object. You could understand perfectly and choose a terrible name deliberately, but I suspect you don't know what to call your things because you haven't decided what they are.
    – Useless
    Feb 25, 2019 at 16:06

1 Answer 1


In terms of OO methodology, I don't believe there's a guideline about which way a reference between objects should point. This is something that is derived as part of the design process i.e. form follows function. In OO methodologies, there are names for these different options and that can assist with the design process.

In UML, for example you have the idea of associations. These can be categorized into aggregations or compositions. These are basically the same with the key difference of whether the associated objects are 'part' of the object that references them (composition) or whether they exist independently (aggregation).

As far as the design goes, it seems reasonable. It strikes me a similar to using generators in Python as a communication channel (using send()). With the approach you are taking the direction of the reference seems to be correct.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.