Six principles of the design model (5): The dimit rule (reproduced)

Six principles of the design model (5): The dimit rule

Definition:An object should have a minimum understanding of other objects.

Problem:The closer the relationship between classes, the greater the coupling degree. When a class changes, the greater the impact on the other class.

Solution:Minimize coupling between classes.

Since we started to engage with programming, we have learned the general principles of software programming: low coupling and high cohesion. Both process-oriented and object-oriented programming can improve the code reuse rate only when the coupling between modules is as low as possible. The advantage of low coupling is self-evident, but how can we program to achieve low coupling? That is exactly what the Demeter rule is about to accomplish.

It was first proposed by Ian Holland at Northeastern University in 1987. In general, a class knows little about its dependent classes as well. That is to say, for the dependent class, no matter how complicated the logic is, we try to encapsulate the logic inside the class as much as possible. In addition to the public method provided, we do not disclose any information externally. The dimit rule also has a simpler definition:Only communicates with direct friends.First, let's explain what a friend is: Every object is coupled with other objects. As long as there is a coupling relationship between two objects, we will say that these two objects are friends. There are many coupling methods, such as dependency, association, combination, and aggregation. The class that appears in the member variables, method parameters, and method return values isDirect friendsBut the class that appears in the local variable is not a friend directly. That is to say, it is better not to appear in the class as a local variable for a strange class.

For example, if a group company has subsidiaries and subordinate departments, you must print the employee IDs of all subordinate units. Let's take a look at the design that violates the Demeter law.

// 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 (); // assign an ID (EMP) to the Branch staff in sequence. setid ("branch" + 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 (); // assign an ID EMP to the company personnel in sequence. setid ("Head Office" + 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 ());}}

The main problem with this design lies in companymanager. According to the Demeter rule, it only communicates with direct friends, the subemployee class is not a direct friend of the companymanager class (coupling with local variables does not belong to a direct friend). Logically, the company can only be coupled with its branch, there is no connection with the staff of the branch office. This design obviously adds unnecessary coupling. According to the Demeter law, we should avoid coupling of such non-direct friend relationships in the class. The modified code is as follows:

Class subcompanymanager {public list <subemployee> getallemployee () {list <subemployee> List = new arraylist <subemployee> (); For (INT I = 0; I <100; I ++) {subemployee EMP = new subemployee (); // assign an ID EMP to the staff of the branch in sequence. setid ("branch" + 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 (); // assign an ID EMP to the company personnel in sequence. 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, the company added the method of printing the staff ID for the Branch Office. The company directly called the method to print the staff, thus avoiding coupling with the staff of the branch office.

The original intention of the dimit rule is to reduce the coupling between classes. Because each class reduces unnecessary dependencies, it can indeed reduce the coupling relationship. However, everything has a degree. Although communication with non-direct classes can be avoided, communication is bound through an "intermediary". For example, in this example, the company contacts its employees through the "intermediary" of the branch. Excessive use of the Demeter principle will produce a large number of such intermediary and transfer classes, resulting in greater system complexity. Therefore, when using the Demeter rule, we must weigh it repeatedly to ensure a clear structure and high cohesion and low coupling.