Six principles of Design pattern (5): Dimitri Law

Definition: An object should have minimal knowledge of other objects.

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.

Head Office staff class employee{Private String ID;PublicvoidSETID (String ID) {This.id = ID; }Public StringGetId () {return ID; } }Branch Staff class subemployee{Private String ID;PublicvoidSETID (String ID) {This.id = ID; }Public StringGetId () {return ID; }} class subcompanymanager{Public list<subemployee>Getallemployee () {list<subemployee> List =New Arraylist<subemployee> ();Forint i=0; i<100; i++) {Subemployee emp =New Subemployee ();Assign an ID emp.setid ("branch" +i) to the branch staff in order; List.add (EMP); }return list; }} class companymanager{Public list<employee>Getallemployee () {list<employee> List =New Arraylist<employee> ();Forint i=0; i<30; i++) {Employee emp =New Employee ();Assign an ID emp.setid ("head Office" +i) in order for head office personnel; 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 Span class= "Hljs-keyword" >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:

Classsubcompanymanager{PublicList<subemployee> Getallemployee () {List<subemployee>List =New Arraylist<subemployee> ();for (int i=0; i<100; i++) {Subemployee emp =New Subemployee ();Assign an ID emp.setid ("branch" +i) to the branch staff in order;List.add (EMP); }ReturnList }public void Printemployee () {List<subemployee>List = This.getallemployee ();For (Subemployee e:List) {System.out.println (E.getid ());}} }Classcompanymanager{public list<employee> Getallemployee () {list<employee> list = new ArrayList< Employee> (); for (int i=0; I<30; i++) { Employee EMP = new employee (); //for the head office personnel in order to assign an ID Emp.setid ("head Office" +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.

Six principles of Design pattern (5): Dimitri Law