Dimit Principle (Least Known Principle): Two classes that do not need to interact directly, if they need to interact, use an intermediary
meaning
- The Demeter principle (
Law of Demeter,LoD) means that an object should keep the least knowledge about other objects. It is also called the least known principle (,Least Knowledge Principle)LKPto try to reduce the coupling between classes. - The less a class knows about the classes it depends on, the better. In other words, for the dependent class, no matter how complex the logic is, the logic should be encapsulated inside the class as much as possible, and no information will be leaked to the outside except the public methods provided. Demeter's Law has a simpler definition: only communicate with direct friends. First, let’s explain what a direct friend is: each object will have a coupling relationship with other objects. As long as there is a coupling relationship between two objects, we say that the two objects are friends. There are many ways of coupling, such as dependency, association, combination, aggregation, etc. Among them, we call the current object itself, the member variables of the current object, and the objects created by the current object. If the member variables of the current object are a set, the elements in the set, method parameters, and classes in the method return value are direct friends . Classes that appear in local variables are not direct friends . In other words, it is best not for unfamiliar classes to appear inside the class as local variables.
- An entity should interact with other entities as little as possible so that the system functional modules are relatively independent. That is to say, a software entity should interact with other entities as little as possible. In this way, when one module is modified, it will affect other modules as little as possible, and expansion will be relatively easy. This is a restriction on communication between software entities. It requires limiting the width and depth of communication between software entities.
main idea
- An object should keep minimal knowledge about other objects
- Reduce the degree of coupling between classes. The closer the relationship between classes, the greater the degree of coupling. When one class changes, the greater the impact on another class. For example, when a class method relies on another class For a class, when the dependent class method changes, the dependent class method must be modified to a new method of the dependent class, which violates the opening and closing principle of the design principle.
advantage
- Reduces the coupling between classes and improves the relative independence of modules
- Due to the reduced affinity, the reusability rate of the class and the scalability of the system are improved.
Case
Now we need to realize the function of people washing clothes. To implement this function we need two classes: a class that represents people and has a method for washing clothes. A class representing a washing machine with three methods for receiving clothes, washing and drying.
public class WashingMachine {
// 接收衣服的方法
public void receiveClothes() {
System.out.println("菜鸟牌洗衣机，开始接收衣服了！");
}
// 洗涤的方法
public void wash() {
System.out.println("菜鸟牌洗衣机，开始洗衣服了！");
}
// 烘干的方法
public void drying() {
System.out.println("菜鸟牌洗衣机，开始烘干衣服了！");
}
}
public class Person {
// 使用洗衣机洗衣服的方法
public void washClothes(WashingMachine washingMachine) {
System.out.println("小菜鸟拿好衣服准备清洗。");
washingMachine.receiveClothes();
washingMachine.wash();
washingMachine.drying();
}
}
The function of washing clothes can be realized through the above two classes, but this implementation does not comply with the least known principle .
In fact, it is very simple. Compared with the Person class, we want to implement the function of washing clothes. How to wash the clothes in the washing machine? We don't need to understand. However, the washClothes method in the Person class above calls three methods of the WashingMachine class in succession. And these three methods are all required by the washing machine and have nothing to do with us humans. This causes the Person class to know too much about the WashingMachine class.
The method to solve this problem is also very simple. The root cause is the class itself. Constrain yourself from the root cause and try not to expose some of your own methods and attributes. It can be simply understood that each class must have its own secret. This allows other classes to know less about themselves.
Case improvements
public class WashingMachine {
// 自动洗衣
public void automatic() {
this.receiveClothes();
this.wash();
this.drying();
}
// 接收衣服的方法
private void receiveClothes() {
System.out.println("菜鸟牌洗衣机，开始接收衣服了！");
}
// 洗涤的方法
private void wash() {
System.out.println("菜鸟牌洗衣机，开始洗衣服了！");
}
// 烘干的方法
private void drying() {
System.out.println("菜鸟牌洗衣机，开始烘干衣服了！");
}
}
public class Person {
// 使用洗衣机洗衣服的方法
public void washClothes(WashingMachine washingMachine) {
System.out.println("小菜鸟拿好衣服准备清洗。");
washingMachine.automatic();
}
}
Excessive use of the Demeter principle will produce a large number of such intermediary and transfer classes, causing the system complexity to increase. Therefore, when adopting Dimit's Law, you must repeatedly weigh the trade-offs to achieve both a clear structure and high cohesion and low coupling.