Design pattern six Principles/Interface design Six principles of the Dee-mitt law

definition: An object should have minimal knowledge of other objects. The Dimitri rule (law of Demeter) is also called the least knowledge principle (Least knowledge Principle shorthand Lkp), that is, one object should have as little understanding of other objects as possible and not speak to strangers. The English shorthand is: LoD.

Objective:The purpose of the Dimitri law is to reduce the coupling between classes. Since each class minimizes its reliance on other classes, it is easy to make the functional modules of the system independent of each other, and there is no (or little) dependency between them.
The Dimitri law does not want a direct connection between classes. If there really is a need to establish a connection, it is also hoped that it will be conveyed through its friend class. Therefore, one of the possible consequences of applying the Dimitri law is that there are a large number of intermediary classes in the system that exist solely to convey the mutual invocation relationship between classes-which in some way increases the complexity of the system.

The problem is: The closer the relationship between classes and classes, the greater the coupling, and the greater the impact on another class when one class changes.

Solution: Minimize the coupling between classes and classes.

Since we began to touch programming, we have learned the general principles of software programming: low-coupling, high cohesion. Whether it is process-oriented programming or object-oriented programming, it is possible to increase the code reuse rate by minimizing the coupling between the modules. The advantages of low coupling are self-evident, but how do you program to do low-coupling? That's exactly what the Dimitri law is going to do.

The Dimitri rule is also known as the least known principle, which was first proposed by Ian Holland of the American Northeastern University in 1987. In layman's terms, it is a class that knows as little as possible about the classes it relies on. That is to say, for a dependent class, no matter how complex the logic, as far as possible to encapsulate the logic inside the class, outside the public method provided, not to disclose any information. The Dimitri rule also has a simpler definition: communicate only with direct friends. let's start by explaining what a direct friend is: Each object has a coupling relationship with other objects, so long as there is a coupling between the two objects, we say that the two objects are friends. There are many ways of coupling, dependence, association, composition, aggregation and so on. In this case, we call the class in the member variable, method parameter, method return value as a direct friend , and the class appearing in the local variable is not a direct friend. In other words, unfamiliar classes are best not to appear inside the class as a local variable.

For example: There is a group company, subordinate units have branch offices and direct departments, now require to print out all subordinate units of the employee ID. First look at the design that violates the Dimitri law.

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465 6667

//总公司员工class Employee{    private String id;    public void setId(String id){        this.id = id;    }    public String getId(){        return id;    }}//分公司员工class SubEmployee{    private String id;    public void setId(String id){        this.id = id;    }    public String getId(){        return id;    }}class SubCompanyManager{    public List<SubEmployee> getAllEmployee(){        List<SubEmployee> list = new ArrayList<SubEmployee>();        for(int i=0; i<100; i++){            SubEmployee emp = new SubEmployee();            //为分公司人员按顺序分配一个ID            emp.setId("分公司"+i);            list.add(emp);        }        return list;    }}class CompanyManager{    public List<Employee> getAllEmployee(){        List<Employee> list = new ArrayList<Employee>();        for(int i=0; i<30; i++){            Employee emp = new Employee();            //为总公司人员按顺序分配一个ID            emp.setId("总公司"+i);            list.add(emp);        }        return list;    }        public void printAllEmployee(SubCompanyManager sub){        List<SubEmployee> list1 = sub.getAllEmployee();        for(SubEmployee e:list1){            System.out.println(e.getId());        }        List<Employee> list2 = this.getAllEmployee();        for(Employee e:list2){            System.out.println(e.getId());        }    }}public class Client{    public static void main(String[] args){        CompanyManager e = new CompanyManager();        e.printAllEmployee(new SubCompanyManager());    }}

Now the main problem of this design is in Companymanager, according to Dimitri Law, only with direct friends, and Subemployee class is not a direct friend of the Companymanager class (the coupling with local variables is not a direct friend), Logically, the head office is only coupled with his branch office, and there is no contact with the staff of the branch, so the design obviously adds unnecessary coupling. In accordance with the Dimitri rule, the coupling of such non-direct friend relationships should be avoided in classes. The modified code is as follows:

123456789101112131415161718192021222324252627282930313233343536373839

class SubCompanyManager{    public List<SubEmployee> getAllEmployee(){        List<SubEmployee> list = new ArrayList<SubEmployee>();        for(int i=0; i<100; i++){            SubEmployee emp = new SubEmployee();            //为分公司人员按顺序分配一个ID            emp.setId("分公司"+i);            list.add(emp);        }        return list;    }    public void printEmployee(){        List<SubEmployee> list = this.getAllEmployee();        for(SubEmployee e:list){            System.out.println(e.getId());        }    }}class CompanyManager{    public List<Employee> getAllEmployee(){        List<Employee> list = new ArrayList<Employee>();        for(int i=0; i<30; i++){            Employee emp = new Employee();            //为总公司人员按顺序分配一个ID            emp.setId("总公司"+i);            list.add(emp);        }        return list;    }        public void printAllEmployee(SubCompanyManager sub){        sub.printEmployee();        List<Employee> list2 = this.getAllEmployee();        for(Employee e:list2){            System.out.println(e.getId());        }    }}

After the modification, for the branch office to increase the printing staff ID method, the head office directly to print, thus avoiding the coupling with the staff of the branch.

The purpose of the Dimitri law is to reduce the coupling between classes, because each class reduces unnecessary dependencies, so it does reduce the coupling relationship. But everything has degrees, although can avoid and non-direct class communication, but to communicate, will inevitably through an "intermediary" to contact, such as in this case, the head office is through the branch of the "intermediary" to contact with the staff of the branch. Excessive use of the Dimitri principle will result in a large number of such intermediaries and transfer classes, resulting in greater complexity of the system. Therefore, in the adoption of Dimitri Law, we should weigh repeatedly, not only to achieve a clear structure, but also high cohesion and low coupling.

Translated from http://blog.jobbole.com/85539/

Design pattern six Principles/Interface design Six principles of the Di-Mitte law (turn)