设计原则之迪米特法则
迪米特法则减少了依赖性，并帮助构建了松耦合的组件，以实现代码重用，更易于维护和可测试性
迪米特法则是开发软件应用程序的设计指南。该原理于1987年在东北大学首次讨论，它指出一个对象永远不应该知道其他对象的内部细节。它旨在促进软件设计中的松耦合。
注意，耦合可以被定义为软件模块之间存在的相互依赖程度以及这种模块彼此之间的紧密连接程度。应用程序中组件之间的耦合越多，随着时间的推移修改和维护它就越难。通过确保应用程序中的组件之间松散耦合，设计易于测试和维护的系统始终是一个好习惯。您可以在这里从我的文章中学到更多有关内聚和耦合的知识。
了解迪米特法则原理
原理指出，模块不应该了解其操作对象的内部细节。换句话说，软件组件或对象不应该了解其他对象或组件的内部工作。让我们通过一个例子来理解德米特定律。
考虑三个类-A，B和C-以及这些类的对象-分别为objA，objB和objC。现在假设objA依赖于objB，而objB则由objC组成。在此场景中，objA可以调用objB的方法和属性，但不能调用objC。
Demeter定律原理利用封装来实现这种隔离并减少应用程序组件之间的耦合。这有助于提高代码质量，并提高灵活性和代码维护难度。遵守Demeter定律的好处是您可以构建易于维护且可适应未来变化的软件。
考虑一个具有方法M的类C。现在假设您创建了一个名为O的类C的实例。Demeter定律指定方法M可以调用以下类型的。，或者类的属性应该调用以下类型仅成员：
相同的对象，即对象“ O”本身
作为参数传递给方法“ M”的对象
本地对象，即在“ M”方法内部创建的对象
对象“ O”可访问的全局对象
对象“ O”的直接组成对象
这是一个代码清单，它说明了遵循Demeter法则的类及其成员。为了清楚起见，我在任何地方都提到了评论。
public class LawOfDemeterExample
{
//This is an instance in the class scope
//and hence this instance can be accessed by any members of this class
AnotherClass instance = new AnotherClass();
public void SampleMethodFollowingLoD(Test obj)
{
DoNothing(); //This is a valid call as you are calling a method of the same class
object data = obj.GetData(); //This is also valid since you are calling a method
//on an instance that has been passed as a parameter
int result = instance.GetResult(); //This is also a valid call as you are calling
//a method on an instance locally created
}
private void DoNothing()
{
// Write some code here
}
}
这是编译以上代码所需的其他两个类。
public class AnotherClass
{
public int GetResult()
{
return -1;
}
}
public class Test
{
public object GetData()
{
return null;
}
}
现在，请参考上面显示的LawOfDemeterExample类。该代码是不言自明的。现在，您可能想知道Demeter定律是否仅适用于方法。答案是不”。得墨Law耳定律原理也适用于性能。
违反Demeter原则的法律
在前面解释的第一个代码示例中，我们通过遵循Demeter原理来开始对此主题的讨论。让我们了解不遵循这一原则会发生什么。考虑下面的代码示例。
var data = new A().GetObjectB().GetObjectC().GetData();
在此示例中，客户端将必须依赖于类A，B和C。换句话说，它与类A，B和C的实例耦合。如果将来这些类发生更改，您将遇到麻烦您将自己暴露于将来任何此类课程中可能发生的变化。