Decoupling using the de moterer rule of the Function

Write "shy"Code:

It contains two meanings: one is not to expose yourself to others, and there is no need to expose anything to other modules; the other is not to deal with too many people, and does not rely on modules implemented by other modules.

Not to deal with too many people, it is to reduce coupling with others. For example, if your module A depends on the function of Module B, then you only call the function of this module B, instead of calling the function of Module C in the implementation of this module, because once the implementation mode of Module B changes, C may not exist, or C may change, then it affects not only B, but also. If a only calls B, even if B's implementation removes the C module, as long as B's interface remains unchanged, a will not be affected, or if c changes, therefore, because a only calls B, c changes will only affect B, but will not affect. Therefore, it is very difficult to change the code of a highly coupled system.

The dimetel law of the function tries to make any givenProgramTo minimize the coupling between modules, it tries to prevent you from entering an object in order to obtain access to the third object method.

Rules and regulations: Any method of an object should only call methods in the following situations:

1. Methods owned by this object;

2. Method for passing in parameters of this method;

3. Method of the object created by this method;

4. Method of the object directly owned by the object;

The Code is as follows:

Class A {Private B = new B (); Private void methode () {} public void methoda (C) {d = new D (); methode (); // 1. You can call C. print (); // 2 the method for passing in the parameters of this method. You can call D. invert (); // 3 method of the object created by this method. You can call B. kill (); // 4 method of the object directly owned by the object. You can call f = B. getf (); F. rock (); // 5This object is dependent on the implementation module of the object and cannot be called.}}
 

Of course, in Demeter's law, since it is not recommended to call Module C that relies on Module B's implementation, you have to write a large number of packaging methods, these methods only forward requests to the delegated user. There is a price and space overhead in the runtime era. If you care about this, you have to balance the performance and maintainability flexibility. For example, you can make some modules tightly coupled for performance. Well, sometimes we have to 'unnormalization' for performance, just like in database design, we use redundancy for some fields to improve access speed and avoid joint queries.

Attachment: Wikipedia's explanation of dimoteer's Law

Law of Demeter is also called the "least knowledge principle". It is a design principle for developing software, especially object-oriented programming, demeter's law is a special case of loose coupling. This guiding principle was invented at Northeastern University in the late 1987 s. It can be summarized as one of the following methods:

1. Each unit has only limited knowledge about other units: Only units closely related to the current Unit;

2. Each unit can only talk to its friends: it cannot talk to a strange unit;

3. Just talk to your friends directly. The name of this principle comes from the Goddess of agriculture in Greek mythology, the lonely dimetel.

PS: Law of Demeter: it seems that there are many translated rules for the former, but it is translated into the latter in the practice of programmers.

References:

1 "Programmer cultivation path"

2 Wikipedia