我有很多需要传递给其他对象的对象。这是一个游戏,所以玩家需要了解世界,世界需要了解地图等。
我没有传递所有这些,而是考虑创建一个“Master”对象管理器,然后用它注册这些对象。我会传递主对象管理器,所有需要的东西都可以执行“masterObject.getPlayer()”或其他任何操作。
这是一个真正的设计模式吗?如果是这样,它叫什么?任何缺点。
答案 0 :(得分:15)
这是一种经常使用的方法,当合理处理时非常有用。虽然有些人不喜欢他们并称他们为“上帝阶级”,但如果结构合理,他们真的不是。如果你把它想象成“拥有一切的类”,问题就会开始出现 - 但是如果你考虑信息结构,你应该没问题。
我们举一个例子。让我们打电话给你对“游戏”感兴趣的课程。这始终是一个好的起点,因为它代表了一个真实世界的实体。游戏应该知道自己的事情:player1,player2,map,turnNumber。在Game上放置方法来访问它们。这是完全正确和良好的设计。然后这些对象将反过来了解自己的事情。玩家将知道名字,技能等级,能量剩余。地图将知道每个方格的大小和地形。如果您需要了解单个方块,那么您可以使用Map类实现getSquare(x,y)。广场知道它的地形类型是什么。
关键是你只需要将方法传递给它所需的东西。计算两个单元之间路径的方法以Map为参数。你不传递游戏,让它提取地图。
许多系统都有这样的对象。 java.lang.Runtime就是一个例子。但是,您应该通过上述技术最大限度地减少使用。
有一个非常重要的诱惑要避免。在您发现几乎所有方法都传递了您的“Master”类之后,您可能会想到“为什么我不将它用于每个方法都可以访问它而不用作参数?”。这就是Singletons。避免。
答案 1 :(得分:2)
你所描述的是一种设计模式,而不是一种反模式。它有时被称为上帝阶级,应该避免。
Wikipedia's article解释了上帝阶级的基本问题。具体来说,这样的对象会违反Law of Demeter。它基本上说不要和陌生人说话。从God对象检索的所有对象都是陌生人,最好避免向他们发送消息/调用方法。
答案 2 :(得分:1)
另一个角度 - 与Will O和Jeune的答案相比 - 是一个很好的旧记录;没有更多,也没有更少。这是正确的设计决定还是“上帝阶级”反模式的实例取决于具体情况。我说没关系,当这个类没有使你的整个代码库相互递归时,并且当该类中没有实际代码时,只需要实例属性来引用所有其他对象。
答案 3 :(得分:0)
试着看看the Observer Pattern。它类似于你所描述的世界。有一个主对象(可观察),并且有一些观察者将自己注册到主对象。如果世界发生了变化,主对象只会通知观察者。
此外,我猜你可以采用其他方法来满足你的需求,但这基本上就是这个概念。