我一直在代码中添加依赖项注入，因为这使得通过代码进行单元测试变得更加容易。

但是，我要求在我的调用链中较高的对象上具有在调用链中更深处的对象的知识。

这是否违反了得墨meter耳定律？如果是这样，这有关系吗？

例如：类A对接口B有依赖关系，要使用的接口的实现被注入到类A的构造函数中。想要使用类A的任何人现在还必须引用B的实现。并且可以称其方法为直接含义，并且了解其子组件(接口B)

Wikipedia关于Demeter的定律说："基本概念是，给定的对象应尽可能少地考虑其他任何事物(包括其子组件)的结构或者属性。"

解决方案

它违反法律吗？
严格来说，我认为是的。
有关系吗？
违反法律的主要危险是使代码更脆弱。
如果我们仅将其仅用于测试，那么危险似乎还算不错。
减轻
我对Demeter定律的理解是，可以通过使用"包装方法"来防止直接调用对象。

它是如何分解的？ DI非常适合最不了解的知识。 DI给我们低耦合对象，彼此之间的防御力较小。

引用维基百科：

...an object A can request a service (call
  a method) of an object instance B, but
  object A cannot “reach through” object
  B to access yet another object...

通常，DI的工作方式完全相同，即我们使用注入组件提供的服务。如果对象尝试访问B的某些依赖项，即它对B的了解很多，则会导致高度耦合并破坏DI的思想。

However I am requiring objects higher
  up my call chain to have knowledge of
  objects further down the call chain

举个例子吗？

如果我对理解正确，那不是由于使用依赖项注入引起的，而是由于使用了模拟策略而导致的，这些策略指定了我们希望方法进行的函数调用。在许多情况下，这是完全可以接受的，但是显然，这意味着我们必须了解所调用的方法，如果我们已指定要执行的操作。

编写好的软件需要权衡取舍。随着实施变得更加完整，它变得更加不一致。我们必须决定这些不一致产生的风险，以及它们是否值得因存在而产生的价值。

依赖注入可能会违反Demeter定律。如果我们强迫使用者进行依赖项的注入。可以通过静态工厂方法和DI框架来避免这种情况。

我们可以通过以下两种方式来设计对象：它们要求传递依赖项，同时具有一种无需显式执行注入就可以使用它们的机制(工厂函数和DI框架)。

得墨meter耳定律规定，对象O的方法M可以调用在M内部创建/实例化的对象的方法。但是，没有任何东西可以指定如何创建这些对象。我认为使用中介对象创建这些对象是完全可以的，只要该对象的生活目的只是代表我们创建其他对象。从这个意义上说，DI不会违反Demeter定律。

要看 ：-)

我认为最好的答案是不正确的，即使在框架下，很多代码也使用了依赖注入并注入了高级对象。然后，我们将获得具有大量依赖关系的意大利面条代码。

依赖注入最适合用于所有会污染对象模型的工作，例如ILogger。如果我们确实注入了业务对象，请确保其处于最低级别，并尝试通过传统方法将其传递给我们。仅在出现混乱时才使用依赖注入。