java对象管理器？设计模式

Question

我有很多对象需要传递给其他对象。这是一个游戏，所以玩家需要了解世界，世界需要了解地图等等

我没有把所有这些都传递出去，而是考虑创建一个“主”对象管理器，然后用它注册这些对象。我会传递主对象管理器，所有需要的东西都可以执行“masterObject.getPlayer（）”或其他操作

这是真正的设计模式吗？如果是，它叫什么？任何不利因素

Answer 1

试试看the Observer Pattern。它很像你描述的世界。有一个主对象（可观察的），也有将自己注册到主对象的观察者。如果世界发生了变化，主对象只会通知观察者

此外，我想你可以加入其他方法来满足你的需求，但这基本上是一个概念

Answer 2

你所描述的是一种设计模式，呃，更确切地说，是一种反模式。它有时被称为神类，应该避免

Wikipedia's article解释了God类的基本问题。具体来说，这样的对象将违反Law of Demeter。基本上就是说不要和陌生人说话。从God对象检索到的所有对象都是陌生人，最好避免向他们发送消息/调用方法

Answer 3

这是一种常用的方法，如果处理得当，可能会非常有用。虽然有些人不喜欢这些课程，称它们为“神课”，但如果结构合理，它们实际上并不存在。如果你把它看作“拥有一切的类”，问题就开始出现了。但是如果你考虑信息结构，你就应该没事了

让我们举个例子。让我们把你感兴趣的班级称为“游戏”。这总是一个好的起点，因为它代表了一个真实世界的实体。一个游戏应该了解自己：玩家1，玩家2，地图，转机号码。在游戏中放置访问这些的方法。这是非常正确的设计。然后这些物体又会了解自己的情况。玩家将知道名字、技能等级和剩余能量。地图会知道每个广场的大小和地形。如果你需要了解一个单独的正方形，那么你可以让Map类实现getSquare（x，y）。广场知道它的地形类型

关键的一点是，你只需要把它需要的东西传递给一个方法。计算两个单元之间路径的方法以Map为参数。你不能通过游戏，让它提取地图

许多系统都有这样的对象。JAVA运行时就是一个例子。然而，你应该通过上述技术来尽量减少它们的使用

有一个非常重要的诱惑需要避免。当你发现你的“Master”类被传递给了几乎所有的方法之后，你可能会想：“为什么我不让每个方法都可以访问这个类，而不把它作为参数使用呢？”。单身汉就是这样。避免

Answer 4

关于这一点的另一个角度——与威尔O和琼的回答相比——是这是一个很好的旧记录；不多也不少。这是正确的设计决策还是“上帝类”反模式的实例取决于具体情况。如果这个类不能使整个代码基相互递归，并且这个类中几乎没有实际代码，那么就只需要引用所有其他对象的实例属性就可以了