OOP: How do I communicate with objects that have a relationship?

Question

Say there are two classes connected to each other through some relationship. For example, a Student maintains a Class list that it accepts, and each Class has a Student list that takes it. Then I’m afraid to let Student directly modify my Class es set, because each modification should be followed by a similar modification to the Class Student s list, and vice versa.

One solution is to have a class whose sole purpose is to keep track of Class - Student relationships, such as Registrar . But then, if any method in Student requires knowledge of its Class list, Student needs to pass Registrar . That seems bad. It seems that Student should not have access to Registrar , where he can also contact other Student s. I can come up with a solution by creating a class that acts as an intermediary between Student and Registrar , showing Student only what he needs to know, but that seems like superfluous. Another solution is to remove from Student any method that needs to access its classes, and place it instead in Registrar or some other class that has access to Registrar .

I ask that I am working on a chess game in Java. I am thinking about the relationship with Piece-Cell and Piece-Player. If it wasn’t normal for Student to have access to Registrar in the above example, here is OK for Piece have access to the Board , since a Piece should look anyway to decide whether any step is valid?

What is the standard practice in such cases?

Answer 1

If the relationship can be changed - the classes should be decoupled as much as possible, so together with each class create an interface, do not enter related relations between the classes. A high level of separation that you can achieve using intermediate services / helpers that encapsulate the communication logic between classes, so in this case you should not introduce one class to another, even both are abstracted by interfaces, basically Student does not know anything about Class , and Class knows nothing about Student . I’m not sure that such complexity makes sense in your case, but in any case you can achieve it.

Here you can find a useful designer of a design pattern that can encapsulate the logic of interaction between two decoupled objects, take a look at it.

Using a mediator template, the relationship between objects is encapsulated by an intermediary object. Objects no longer directly communicate with each other, but instead communicate through an intermediary. This reduces dependencies between transmitted objects, thereby reducing traction.

Answer 2

I think you found in your rather pleasant example and explanation that OO does not solve all problems. As long as the responsibility is well formed and sharp, everything is in order. And as soon as each responsibility fits exactly into one bucket (class), it is quite easy to design. But here you have a compromise:

• If I define a separate class for each responsibility, I get a bloated design that is pretty hard to understand (and sometimes maintain).
• If I include at least one interface for each individual responsibility, I will get more classes and interfaces than I need.
• If I decide that one of the two classes is responsible for this relationship, this one object has more knowledge than usual about the other.
• And if you imagine in each case a pick or something similar, your design will be more complex than the problem.

Therefore, perhaps you should ask questions:

• What is the likelihood of a change in the relationship between two objects?
• What is the likelihood that a relationship will exist between more than 1 type of objects at each end?
• Is this part of the system a very visible part, so that many other parts will interact with it (and therefore will depend on it)?

Take the simplest solution that could work and start with that. While the solution remains simple, this is only your code (you do not create a library for others), it is likely that you can change the design later without problems.

So, in your specific case

• board field must have access to the entire XOR board
• the figure on the field must be responsible for moving XOR
• there must be an object type (ChessGame?), which is responsible for the general knowledge of movement, blocking, attack ...

I really think that all of them are valid, and it depends on your special "business case", which is most important.