design-patterns - 依赖注入(inject)链接是一种反模式吗？

Question

这就是问题所在，假设我们正在制作一个视频游戏并且想要使用依赖注入(inject)。这是我们所拥有的:

Game Class  // This is just the code to keep track of the overall game logic
Character Class // This would be the guys in the game, good and bad guys both
Weapon Class // The weapons for the characters

所以通常当我进行依赖注入(inject)时，我会将 map 上的当前位置和游戏状态注入(inject)角色，这样我的角色就​​会知道在哪里创建自己，等等。然后我让角色创建武器并注入(inject)关于武器强度的值，以及来自游戏类的其他一些一般游戏状态等。

这对我来说几乎是一种反模式。我这么说是因为现在您拥有(至少在我看来如此)非常脆弱且难以更改的代码。如果我们想更改传递的游戏状态信息，我们必须更改所有三个类。我们对 Game 类进行原始更改，然后修改 Character，最后也修改 Weapon 类。这是很多工作，尤其是如果您要深入 5 个级别，而不仅仅是这里的 3 个级别。虽然是的，但它比没有 DI 更容易进行单元测试。

这听起来又像是不好的做法。这是通常做事的方式吗？我们有一种“母舰”模式，一切都在顶层。因此，我们让游戏(或其他类)创建所有武器，而不是游戏创建角色创建武器。

这样，如果我们想为角色添加新武器，游戏类可以自己创建武器并注入(inject)它。不知道该怎么做。谢谢

Answer 1

链接或嵌套依赖项是一种非常自然的做法(尽管我必须同意 tster 你的示例听起来有点奇怪)，但我想我可以理解为什么你会觉得它很脆弱——也就是说，如果你将具体类型注入(inject)他们的消费者。

诀窍是在每个依赖级别引入一个接口(interface)，以便您可以独立于消费者改变实现 .例如，您应该定义一个 IGame接口(interface)并将其注入(inject)Character类而不是 Game类本身。

即便如此，具有大量深度嵌套的接口(interface)仍然很脆弱，因为您可能需要经常更改接口(interface)本身。这最好通过努力遵守 Hollywood Principle 来解决。和 Law of Demeter越多越好。