OOP：我如何处理相互关系的对象？

Question

假设通过某种关系有两个相互关联的类。例如，Student维护一个Class es列表，每个Class都有一个Student列表。然后我害怕Student能够直接修改其Class es的集合，因为每次修改后都必须对Class的{​​{1}}列表进行类似的修改。 Student s，反之亦然。

一个解决方案是创建一个类，其唯一目的是跟踪Class - Student关系，例如Registrar。但是，如果Student中的某个方法需要了解其Class列表，则Student需要传递Registrar。这看起来很糟糕。似乎Student不应该访问Registrar，它也可以访问其他Student。我可以想到一个解决方案，创建一个充当Student和Registrar之间的中介的类，只显示它需要知道的Student，但这似乎有点矫枉过正。另一种解决方案是从Student中删除需要访问其类的任何方法，并将其放在Registrar或其他有权访问Registrar的类中。

我问的原因是我正在使用Java进行国际象棋游戏。我正在考虑Piece-Cell关系和Piece-Player关系。如果在上面的示例中，Student无法访问Registrar，那么Piece是否可以访问Board，因为Piece需要环顾四周来决定移动是否有效？

在这种情况下，标准做法是什么？

Answer 1

如果关系可以改变 - 类应该尽可能地解耦，所以随着每个类创建一个接口，不要在类之间引入绑定关系。 使用封装类之间通信逻辑的中间服务/帮助程序可以实现高级别的分离，因此在这种情况下，您不应该将一个类注入到另一个类中，即使两个类都被接口抽象，基本上Student也不知道任何事情大约Class，而Class对Student一无所知。我不确定这种复杂性在你的情况下是否有意义，但无论如何你都可以实现它。

您可以在这里找到一个有用的design pattern Mediator，它可以封装两个解耦实体之间的交互逻辑，看看它。

  

使用中介模式，对象之间的通信就是   用中介对象封装。对象不再通信   彼此直接相关，而是通过相互沟通   调解员。这减少了通信对象之间的依赖关系，   从而降低了耦合。

Answer 2

我认为你在你非常好的例子和解释中找到的是OO并没有很好地解决所有问题。只要责任​​形状和锐利，一切都很好。只要每个职责只适合一个桶（该类），它就很容易设计。但在这里你有一个权衡：

• 如果我为每个职责定义一个单独的课程，我会得到一个很难理解（有时候难以理解）的臃肿设计。
• 如果我为每个单独的职责包括至少一个界面，我将获得比我需要的更多的类和接口。
• 如果我认为这两个类中的一个也对这个关系负责，那么这一个对象比另一个对象有更多的知识。
• 如果你在每种情况下介绍一个调解员或类似的东西，你的设计将比问题更复杂。

所以也许你应该问问题：

• 两个对象之间的关系发生变化的可能性有多大？
• 两端的更多1种对象之间存在关系的可能性是多少？
• 系统中那部分是一个非常明显的部分，所以很多其他部分会与它接口（因此会依赖它）？

采用可能有效的最简单的解决方案并从中开始。只要解决方案保持简单，只有您的代码（您不为其他人设计库），您可以稍后更改设计而不会有麻烦。

所以在你的具体案例中，

1. 电路板字段应该可以访问整个电路板XOR
2. 该字段上的数字应该负责移动XOR
3. 应该有一个对象类型（ChessGame？）负责有关移动，阻止，攻击的整体知识......

我认为一切都是有效的，这取决于你的特殊“商业案例”，哪一个是最有效的。