两个彼此依赖的对象。那不好吗？

Question

当我为我的项目构建自己的系统时，我正在学习很多关于设计模式的知识。我想问你一个我无法找到答案的设计问题。

目前我正在使用具有多个客户端的套接字构建一个小型聊天服务器。现在我有三个班级：

1. 人类，其中包含昵称，年龄和房间对象等信息。
2. 房间级，其中包含房间名称，主题和当前房间中人员列表等信息。
3. 酒店级，其中包含人员列表和服务器上的客房列表。

我做了一个图来说明它：

我在酒店级服务器上有一个人员列表，因为现在跟踪在线有多少人会很好（不必遍历所有房间）。 这些人住在酒店级，因为我希望能够在不搜索房间的情况下搜索特定的人。

这是一个糟糕的设计吗？还有另一种实现方式吗？

感谢。

Answer 1

我不喜欢它。酒店包含客房，房间包含人。人们不包含房间，他们属于他们。

您不一定要迭代来计算您的访客数量。您可以保持运行计数（$ Hotel-＆gt; total_guests）并在其更改时进行修改。

Answer 2

严格来说，类之间的相互依赖问题可以通过使用接口来解决（抽象类，如果您的语言是例如C ++或Python）IRoom和{{1} };在伪代码中

IPerson

这只会使 interfaces 相互依赖 - 接口的实际实现只需要依赖于接口。

如果你想避免使用循环引用循环（这可能会让你感到麻烦，例如在CPython中通过减慢垃圾收集速度），这也为你提供了很多实现余地 - 你可以使用弱引用，具有典型“一对多关系”表的基础关系数据库等等。对于第一个简单原型，您可以使用所选语言中最简单的（可能简单，并且必然是循环，引用[[指针，在C ++]]中，interface IPerson IRoom getRoom() // etc interface IRoom iter<IPerson> iterPerson() // etc 引用Person，Room引用Room。

Answer 3

在一个更大的系统中，它会很糟糕，但是从我对你的应用程序的理解来看，这三个类只是一起使用，这不是什么大问题。只需确保以某种方式命名该人的成员变量，该方式表明它包含对房间的引用，而不是实例。

此外，除非出于性能原因（例如，您将拥有大量的房间），否则制作一个可以在房间内迭代并收集人员的财产或吸气器可能会更加清洁，而不是将其缓存在酒店。

Answer 4

相互依赖本身并不坏。有时数据使用需要它。

我以不同的方式思考它。维护一般关系较少的代码（相互依赖与否）会更容易。尽量保持简单。对于你的情况来说，唯一的另一个棘手问题是在创建和删除序列期间有时会出现检查和鸡蛋问题。你有更多的预订链接。

如果您在这种情况下询问是否需要酒店的人员名单，我认为有两个答案。我首先让你的对象（在内存中）提供这些关系，但你不需要在数据库中的人和酒店之间有一个额外的连接表。如果你正在使用Hibernate，它会自动生成一个有效的连接，如果你要求酒店的人（它将加入rooms.hotel_id上的酒店）。