design-patterns - 将 DEMETER 定律应用于外观模式

Question

在敏捷开发人员的基本技能中，在需求与能力接口(interface)中，第 12 章，我试图理解作者在本章末尾提到的应用分度法则的挑战所提出的主要解决方案。

为了使故事简短。

我们从以下研究案例开始:

public class City {
  public string name{};
  public City twinCity{};
  public Street[] streets{};
}
public class Street {
  public string name{};
  public House[] houses{};
}
public class House {
  public int number{};
  public Color color{};
}

作者声明:

Models like this encourage us to expose rather than to encapsulate. If your code has a reference to a particular City instance, say one that maps Seattle, and you wanted the color of the house at 1374 Main Street, then you might do something like the following:

public Foo() {
  Color c = Seattle.streets()["Main"].
    houses()[1374].
    color();
}

The problem, if this is done as a general practice, is that the system develops dependencies everywhere, and a change to any part of this model can have effects up and down the chain of these dependencies. That’s where the Law of Demeter, which states2 “Don’t talk to strangers,” comes in. This is formalized in object systems as the Law of Demeter for Functions/Methods. A method M of an object O may only invoke the methods of the following kinds of objects:

1. O’s
2. M’s parameters
3. Any objects instantiated within M
4. O’s direct component objects
5. Any global variables accessible by O

并建议在应用 DEMTER 法则时，我们应该瞄准类似的东西

public Foo() {
   Color c = Seattle.ColorOfHouseInStreet("Main",1374);
}

并迅速从以下方面发出警告:

Although this would seem to be a wise policy initially, it can quickly get out of hand as the interface of any given entity can be expected to provide literally anything it relates to. These interfaces tend to bloat over time, and in fact there would seem to be almost no end to the number of public methods a given glass may eventually support.

然后在解释了耦合和依赖问题后，他提到了通过服务的接口(interface)分离客户端及其服务的重要性，并且可能进一步将客户端“需要接口(interface)”与“服务能力”分离接口(interface)”通过使用适配器作为理想但不一定实用的东西；



他建议，为了解决这个问题，我们可以结合 DEMETER 法则和需求/能力分离，使用外观模式，如下所述:

从原始依赖



在应用 demeter 定律和需求/能力接口(interface)分离时，我们最初应该得到:



但是考虑到它是不切实际的，特别是从模拟的角度来看，我们可以用下面的外观来做一些更简单的事情:




问题是我只是不明白这究竟是如何解决不违反得墨忒耳法则的问题。我认为它维护了原始客户和原始服务之间的法律。但它只是在 FACADE 内移动了违规行为。

Answer 1

我想说，根据您的描述，他只是以 CityMapFacade 的形式围绕 Cirty/Street/House 功能引入了一个黑盒组件。此外，该组件以接口(interface) IClientNeeds 的形式遵循面向公众的接口(interface)。这种黑盒封装保护了更大的应用程序并使其可测试，因为城市/街道/房屋关系的复杂性没有暴露出来。似乎曾经的旧东西又是新的了 :) 这种黑盒组件式方法(因为没有更好的术语)已经存在了很长时间。它专注于创建具有良好定义接口(interface)的可重用、封装的功能组件。只要履行了面向公众的契约(Contract)，客户就不会关心实现。该组件是可替换的、可升级的、可模拟的。在组件内，复杂性也降低了，因为它只负责应用程序的一个孤立子集。它通常是完全可单元测试的，以确保它正确实现其公共(public)合约/接口(interface)。在我看来，作者已经对这一切进行了更深入的讨论，以简化他的解释。