Six major principles of design pattern (5): Dimitri Law

Definition: An object should maintain a minimal understanding of other objects.
The problem: The closer the relationship between classes and classes, the greater the degree of coupling, the greater the impact on another class when a class changes.
Solution: Reduce the coupling between classes and classes as much as possible.
Since we began to contact programming, we know the general principles of software programming: low coupling, high cohesion. Whether the process-oriented programming or object-oriented programming, only to make the coupling between each module as low as possible to improve the code reuse rate. The advantages of low coupling are self-evident, but how can programming be done with low coupling? That's exactly what the Dimitri law is going to do.
The Dimitri rule, also called the least known principle, was first proposed by Ian Holland of the American Northeastern University in 1987. In layman's terms, it is a class that knows less about the classes it relies on. In other words, for the dependent classes, no matter how complex the logic is, try to encapsulate the logic within the class as much as possible and not disclose any information outside the public method provided. The Dimitri Law also has a simpler definition: only communicate with direct friends. First, explain what a direct friend is: Each object has a coupling relationship with other objects, so long as the two objects are coupled, we say the two objects are friends. There are many ways of coupling, dependence, association, combination, aggregation and so on. Among them, we call the class in the member variable, method parameter, method return value as the 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 as local variables inside the class.
To cite an example: there is a group company, subordinate units have branches and immediate departments, now require the printing of all subordinate units of the employee ID. Let's take a look at the design that violates the Dimitri law.
[Java] View plaincopy
Head office staff
Class employee{
Private String ID;
public void SetId (String id) {
This.id = ID;
}
Public String getId () {
return ID;
}
}

Branch Staff
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 in order for the branch staff
Emp.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 in order for head office personnel
Emp.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 ());
}
}
Now the main problem with this design is in Companymanager, according to the Dimitri Law, only communicate with the direct friends, and the Subemployee class is not a direct friend of the Companymanager class (the coupling with local variables does not belong to direct friends), Logically speaking, the head office is only coupled to his branch, and there is no connection with the staff of the branch, so the design obviously adds unnecessary coupling. In accordance with the Dimitri rule, you should avoid the coupling of such indirect relationships in a class. The modified code is as follows:
[Java] View plaincopy
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 in order for the branch staff
Emp.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 in order for head office personnel
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 ());
}
}
}
Modified, for the branch office to increase the number of printing staff ID method, the head office directly to print, so as to avoid coupling with the staff of the branch.
The Dimitri principle is designed to reduce coupling between classes, and because each class reduces unnecessary dependencies, it does reduce the coupling. But everything has the degree, although can avoid with not direct class communication, but to communicate, will inevitably through an "intermediary" to contact, for example, in this case, the head office through the branch of this "intermediary" to contact with the staff of the branch. Excessive use of the Dimitri principle, will produce a large number of such intermediary and transfer classes, resulting in a greater complexity of the system. Therefore, the use of Dimitri rules to be weighed repeatedly, not only to achieve a clear structure, but also high cohesion low coupling.