包装器/德米特法则似乎是一种反模式

Question

我一直在阅读“德米特定律”的内容，它（以及一般的纯“包装”类）似乎通常是反模式。考虑一个实现类：

class FluidSimulator {
    void reset() { /* ... */ }
}

现在考虑另一个类的两种不同实现：

class ScreenSpaceEffects1 {
    private FluidSimulator _fluidDynamics;
    public FluidSimulator getFluidSimulator() { return _fluidDynamics; }
}

class ScreenSpaceEffects2 {
    private FluidSimulator _fluidDynamics;
    public void resetFluidSimulation() { _fluidDynamics.reset(); }
}

以及调用所述方法的方式：

callingMethod() {
   effects1.getFluidSimulator().reset(); // Version 1
   effects2.resetFluidSimulation();      // Version 2
}

乍一看，版本 2 似乎更简单一些，并且遵循“Demeter 规则”，隐藏 Foo 的实现等。但这会将 FluidSimulator 中的任何更改与 ScreenSpaceEffects 联系起来。例如，如果添加一个参数来重置，那么我们有：

class FluidSimulator {
    void reset(bool recreateRenderTargets) { /* ... */ }
}

class ScreenSpaceEffects1 {
    private FluidSimulator _fluidDynamics;
    public FluidSimulator getFluidSimulator() { return _fluidDynamics; }
}

class ScreenSpaceEffects2 {
    private FluidSimulator _fluidDynamics;
    public void resetFluidSimulation(bool recreateRenderTargets) { _fluidDynamics.reset(recreateRenderTargets); }
}

callingMethod() {
   effects1.getFluidSimulator().reset(false); // Version 1
   effects2.resetFluidSimulation(false);      // Version 2
}

在两个版本中，callingMethod都需要更改，但在版本2中，ScreenSpaceEffects也需要更改。有人可以解释一下拥有包装器/外观的优点（适配器或包装外部 API 或公开内部 API 除外）。

编辑：这是我遇到的许多真实示例之一，而不是一个微不足道的示例。

Answer 1

主要区别在于，在版本 1 中，作为 Bar 抽象的提供者，您无法控制 Foo 的公开方式。 Foo 中的任何更改都会暴露给您的客户，他们将不得不忍受它。

在版本 2 中，作为抽象 Bar 的提供者，您可以决定是否以及如何公开演变。它将仅依赖于 Bar 抽象，而不依赖于 Foo 的抽象。在您的示例中，您的 Bar 抽象可能已经知道要传递哪个整数作为参数，因此您将能够让您的用户透明地使用新版本的 Foo，完全没有变化。

假设现在 Foo 进化了，并要求用户在调用 doSomething 之前调用 foo.init()。在版本 1 中，Bar 的所有用户都需要看到 Foo 发生了变化，并调整他们的代码。在版本 2 中，只需更改 Bar，如果需要，它的 doSomething 会调用 init。这会导致更少的错误（只有抽象 Bar 的作者必须了解和理解抽象 Foo 以及减少类之间的耦合。

Answer 2

这显然是一个人为的例子。在许多实际情况下，callingMethod（在现实生活中，可以有多个callingMethods）可以幸福地不知道Foo.doSomething已经改变，因为Bar将其隔离。例如，如果我使用稳定的打印 API，我就不必担心打印机固件会添加对光泽打印的支持。我现有的黑白打印代码可以继续工作。我想你会把它分组在“适配器”下，我认为它比你暗示的更常见。

你是对的，有时调用方法也必须改变。但是，当正确使用德米特定律时，这种情况只会很少发生，通常是为了利用新功能（与新界面不同）。

编辑：callingMethod 似乎很可能不关心是否重新创建渲染目标（我假设这是性能与准确性的问题）。毕竟，“我们应该忘记小效率，大约 97% 的时间”（Knuth）。因此，ScreenSpaceEffects2 可以添加一个 resetFluidSimulation(bool) 方法，但通过调用 _fluidDynamics.reset(true)< 让 resetFluidSimulation() 继续工作（无需更改 CallingMethod）< /code> 幕后。

Answer 3

问题是，callingMethod() 是否需要知道是否重新创建渲染表？

假设某些给定的 callingMethod() 执行需要或不需要重新创建渲染表。在这种情况下，您可以使用新方法扩展包装器。然后，您只需从适当的 callingMethod() 实例中调用新方法即可。

class ScreenSpaceEffects2 {
    private FluidSimulator _fluidDynamics;
    public void resetFluidSimulation() { _fluidDynamics.reset(false); }
    public void resetFluidSimulationWithRecreate() { _fluidDynamics.reset(true); }
}

或者，重新创建的决定可能完全属于其他地方……

class ScreenSpaceEffects2 {
    private FluidSimulator _fluidDynamics;
    public void resetFluidSimulation() { 
             _fluidDynamics.reset( someRuleEngine.getRecreateRenderTables() ); }
}

在这种情况下，callingMethod() 中的任何内容都不需要更改。