如何解决违反迪米特法则的问题？

我和一位同事为我们的客户设计了一个系统，我们认为我们创建了一个漂亮简洁的设计。但我对我们引入的一些耦合遇到了问题。我可以尝试创建一个示例设计，其中包含与我们的设计相同的问题，但如果您原谅我，我将创建我们设计的摘录来支持该问题。

我们正在开发一个用于注册患者某些治疗的系统。为了避免图像链接断开，我将概念性 UML 类图描述为 C# 样式类定义。

class Discipline {}
class ProtocolKind 
{ 
   Discipline; 
}
class Protocol
{
   ProtocolKind;
   ProtocolMedication; //1..*
}
class ProtocolMedication
{
   Medicine;
}
class Medicine
{
   AdministrationRoute;
}
class AdministrationRoute {}

我将尝试解释一些有关设计的内容，协议是新治疗的模板。方案是某种类型的并且包含需要施用的药物。根据协议，同一种药物（除其他外）的剂量可能有所不同，因此存储在 ProtocolMeduction 类中。 AdministrationRoute 是与方案管理分开的药物施用和创建/更新的方式。

我发现以下地方违反了德墨忒尔法则：

违反德墨忒尔法则

球内部

例如，在协议药物的业务逻辑内部，存在依赖于药物的管理路线.可溶性属性的规则。代码将变成

if (!Medicine.AdministrationRoute.Soluble)
{
   //validate constrains on fields
}

存储库内部

列出某个学科中所有协议的方法将写为：

public IQueryable<Protocol> ListQueryable(Discipline discipline)
{
    return ListQueryable().Where(p => (p.Kind.Discipline.Id == discipline.Id)); // Entity Frameworks needs you to compare the Id...
}

用户界面内部

我们使用 ASP.NET（无 MVC）作为我们系统的接口，在我看来，这一层目前存在最严重的违规行为。 gridview的数据绑定（必须显示协议Discipline的列必须绑定到Kind.Discipline.Name），它们是字符串，所以没有编译时错误.

<asp:TemplateField HeaderText="Discipline" SortExpression="Kind.Discipline.Name">
   <ItemTemplate>
      <%# Eval("Kind.Discipline.Name")%>
   </ItemTemplate>
</asp:TemplateField>

所以我认为真正的问题可能是，什么时候可以将其更多地视为德墨忒尔的建议，以及可以采取什么措施来解决违反德墨忒尔定律的问题？

我对自己有一些想法，但我会将它们作为答案发布，以便可以单独评论和投票。 （我不确定这是这样做的方式，如果不是，我会删除我的答案并将它们添加到问题中）。

我对 Demeter 定律的后果的理解似乎与 DrJokepu 的不同 - 每当我将其应用于面向对象的代码时，它都会导致更紧密的封装和内聚，而不是在过程代码中的契约路径中添加额外的 getter。

维基百科有这样的规则

更正式地说，迪米特定律 函数要求方法 M 为 对象 O 只能调用 方法有以下几种 对象：

1. O itself
2. M的参数
3. M 内创建/实例化的任何对象
4. O 的直接组件对象

如果你有一个以“厨房”为参数的方法，Demeter 说你不能检查厨房的组件，而不是说你只能检查直接组件。

编写一堆函数只是为了满足像这样的迪米特定律

Kitchen.GetCeilingColour()

看起来对我来说完全是浪费时间，但实际上这是我完成工作的方式

如果 Kitchen 外部的方法传递给 kitchen，则根据严格的 Demeter，它也不能针对其上的 GetCeilingColour() 结果调用任何方法。

但无论哪种方式，重点是消除对结构的依赖，而不是将结构的表示从一系列链接方法移动到方法名称。在 Dog 类中创建诸如 MoveTheLeftHindLegForward() 之类的方法对于实现 Demeter 没有任何作用。相反，调用dog.walk()并让狗处理自己的腿。

例如，如果需求发生变化并且我也需要天花板高度怎么办？

我会重构代码，以便您可以使用房间和天花板：

interface RoomVisitor {
  void visitFloor (Floor floor) ...
  void visitCeiling (Ceiling ceiling) ...
  void visitWall (Wall wall ...
}

interface Room { accept (RoomVisitor visitor) ; }

Kitchen.accept(RoomVisitor visitor) {
   visitor.visitCeiling(this.ceiling);
   ...
}

或者，您可以更进一步，通过将天花板的参数传递给visitCeiling方法来完全消除吸气剂，但这通常会引入脆弱的耦合。

将其应用到医学示例中，我希望 SolubleAdminstrationRoute 能够验证药物，或者至少调用药物的 validateForSolubleAdministration 方法（如果药物类中封装了验证所需的信息）。

然而，Demeter 适用于 OO 系统，其中数据被封装在对数据进行操作的对象中，而不是您正在谈论的系统，后者具有不同的层，数据以哑的、可导航的结构在层之间传递。我不认为 Demeter 一定可以像应用于整体系统或基于消息的系统一样容易地应用于此类系统。 （在基于消息的系统中，您无法导航到消息克之外的任何内容，因此无论您喜欢与否，您都会被 Demeter 困住）