Six principles of Design pattern (5)--Dimitri Principle

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 know 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, how to program to achieve low coupling?

Dimitri Law is also known as the least known principle, the earliest was 1987 by the United States Norigheastern University LAN Holland proposed. In layman's terms, it is a class that knows as little as possible about the classes it relies on. In other words, 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. Where we call the class that appears member variable, method parameter, method return value to be a direct friend. now the class 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.

To cite an example: there is a group company, subordinate units have branch offices and direct departments, now require to print the employee ID, in addition to all subordinate units. First look at the design that violates the Dimitri law.

1 //Head office Staff2 classemployee{3     PrivateString ID;4      Public voidsetId (String id) {5          This. ID =ID;6     }7      PublicString getId () {8         returnID;9     }Ten } One  A //employees of the company - classsubemployee{ -     PrivateString ID; the      Public voidsetId (String id) { -          This. ID =ID; -     } -      PublicString getId () { +         returnID; -     } + } A  at classsubcompanymanager{ -      PublicList<subemployee>Getallemployee () { -list<subemployee> list =NewArraylist<subemployee>(); -          for(inti=0; i<100; i++){ -Subemployee emp =NewArraylist<subemployee>(); -             //assign an ID in order for a branch office person inEmp.setid ("branch" +i); - List.add (EMP); to         } +         returnlist; -      } the } *  $ classcompanymanager{Panax Notoginseng       PublicList<employee>Getallemployee () { -list<employee> list =NewArraylist<employee>(); the           for(inti=0; i<30; i++){ +Employee emp =NewEmployee (); A              //assign an ID in order for head office personnel theEmp.setid ("head Office" +i); + List.add (EMP); -           } $           returnlist; $       } -  -        Public voidPrintallemployee (Subcompanymanager sub) { theList<subemployee> List1 =Sub.getallemployee (); -            for(Subemployee e:list1) {Wuyi System.out.println (E.getid ()); the           } -  WuList<employee> List2 = This. Getallemployee (); -            for(Employee e:list2) { About System.out.println (E.getid ()); $           } -       } - } -  A  Public classclient{ +       Public Static voidMain (string[] args) { theCompanymanager e =NewCompanymanager (); -E.printallemployee (NewSubcompanymanager ()); $       } the}

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:

1 classsubcompanymanager{2      PublicList<subemployee>Getallemployee () {3list<subemployee> list =NewArraylist<subemployee>();4          for(inti=0; i<100; i++){5Subemployee emp =NewSubemployee ();6             //assign an ID in order for a branch office person7Emp.setid ("branch" +i);8 List.add (EMP);9          }Ten          returnlist; One      } A       Public voidPrintemployee () { -list<subemployee> list = This. Getallemployee (); -           for(Subemployee e:list) { the System.out.println (E.getid ()); -          } -      } - } +  - classcompanymanager{ +      PublicList<employee>Getallemployee () { Alist<employee> list =NewArraylist<employee>(); at          for(inti=0; i<30; i++){ -Employee emp =NewEmployee (); -             //assign an ID in order for head office personnel -Emp.setid ("head Office" +i); - List.add (EMP); -         } in         returnlist; -     } to  +      Public voidPrintallemployee (Subcompanymanager sub) { - Sub.printemployee (); theList<employee> List2 = This. Getallemployee (); *          for(Employee e:list2) { $ System.out.println (E.getid ());Panax Notoginseng         } -     } the}

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, the use of Dimitri law should be weighed repeatedly, that is, to achieve a clear structure, but also high cohesion and low coupling.

Transferred from: http://blog.csdn.net/zhengzhb/article/details/7296930

Six principles of Design pattern (5)--Dimitri Principle