Question

这是问题所在，假设我们正在制作视频游戏，并希望使用依赖注入。这就是我们所拥有的：

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

通常情况下，当我执行依赖注入时，我会在地图上注入当前位置，并将游戏状态注入角色，这样我的角色就可以知道在哪里创建自己的信息等等。然后我让角色创建武器并注入关于武器强度的值，以及游戏类等的其他一般游戏状态。

这对我来说几乎是一种反模式。我之所以这么说是因为现在你（至少对我来说似乎这样）的代码非常脆弱且难以改变。如果我们想要更改传递的游戏状态信息，我们将被迫更改所有三个类。我们对Game类进行了原始更改，然后修改了Character，最后修改了Weapon类。这是很多工作，特别是如果你要深入5级而不仅仅是3级。虽然是的，它可以让单位测试比没有DI更容易。

这听起来像是不好的做法。这是通常的事情吗？我们有什么样的“MotherShip”模式，一切都处于最顶层。因此，不是游戏创造角色创造武器，我们让游戏（或其他一些类）创造所有这些。

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

Answer 1

链接或嵌套依赖是一种非常自然的做法（虽然我必须同意tster，你的例子听起来有点奇怪），但我想我能理解为什么你发现它很脆弱 - 也就是说，如果你注入具体的类型他们的消费者。

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

即使如此，具有大量深度嵌套的接口仍然可能很脆弱，因为您可能需要经常更改接口本身。最好通过努力尽可能地符合Hollywood Principle和Law of Demeter来解决这个问题。

Answer 2

设计问题很难回答，特别是当这个例子似乎没有意义时。在这种情况下，角色创造武器是没有意义的。角色应该对这一个角色负责。也许你可以为角色添加武器，但是，除非角色是武器制造者，否则我认为它实际上不会创建一个新的武器类。

顺便说一句，我认为比其中任何一种都更好的模式是工厂模式。创建一个负责创建武器的类。还有一个负责创建角色的类。这样，如果创建一个角色时需要更改3个或4个位置，那么该工厂可以处理该行为，并将其包含在将来的更改中。

依赖注入链接反模式吗？

2 个答案: