Six design principles of Zen design pattern-Dimitri principles

Dimitri Law


One: The Dimitri rule defines:
----> Dimitri (Law of Demeter,lod) is also known as the least-knowledge principle (Least knowledge
PRINCIPLE,LKP),
----> An object should have a minimal understanding of other objects. In layman's words, a class should know the least about the classes that it needs to be coupled or called, and how complex the internals of your (coupled or called classes) are to me, that's your business, and I know that you provide so many public methods that I call so much that the rest of me doesn't care.

Second: The Dimitri Law gives a clear requirement for low coupling of classes.
---> Communicate with friends only. "In a business scenario, try to communicate with fewer friends and reduce coupling."
(1) The Dimitri Law also has an English explanation: only the talk to your immediate friends (communicates only with direct friends. What is a direct friend? Each object is bound to have a coupling relationship with other objects, and the coupling between two objects becomes a friend, and there are many types of relationships, such as composition, aggregation, dependency, and so on. Below we will give an example of how we can only communicate with direct friends.
(2) The definition of a friend class is this: The class that appears in the member variable, the input and output parameters of the method is called the member Friend class, and the class that appears inside the method body does not belong to the friend class
(3) A class only communicates with friends, does not communicate with unfamiliar classes, does not appear geta (). GETB (). GetC (). GETD () This situation (in the extreme case of allowing such access, i.e. the return type after each dot is the same), the relationship between classes and classes is built between classes, Rather than methods, so a method tries not to introduce objects that do not exist in a class, except, of course, the classes provided by the JDK API.

---> Friends are also very close to each other. "To provide as few public methods as possible to a dependent class"
(1) The more public properties or methods are exposed by a class, the greater the number of faces involved in the modification, and the greater the risk spread caused by the change. Therefore, in order to maintain the distance between friends, the design needs to be repeatedly measured: whether the public methods and properties can be reduced, whether it can be modified to private, package-private (package type, without access to classes, methods, variables, the default is the package type), Protected such as access, whether you can add the final keyword, and so on.
(2) Dimitri Law requires the class "shy" a little, try not to publish too many public methods and non-static variables, as far as possible, more introverted, use private, package-private, protected and other access rights.

---> Is your own.
(1) In the practical application often appears such a method: Put in this class also can, put in other class also is not wrong, how to measure? You can stick to the principle that if a method is placed in this class, neither increasing the relationship between the classes nor negatively affecting the class, it is placed in this class.

---> Cautious use of serializable
(1) In practical applications, this problem is rarely seen, even if it is immediately discovered and resolved. What's going on? For example, in a project that uses RMI (the remote method invocation, which is called remotely) to pass a VO (value object), this object must implement the Serializable interface ( is just a symbolic interface, do not need to implement a specific method), that is, the need for network transmission of the object to serialize, otherwise there will be notserializableexception exception. Suddenly one day, the client's VO modified the access rights of a property, from private to public, access rights widened, if the server did not make the corresponding changes, it will be reported serialization failure, it is so simple.


Third, best practices
The core idea of the law of the----> Dimitri is the decoupling between classes, weak coupling, and the reuse rate of classes can be improved only after weak coupling. The result of the request is that a large number of relays or jump classes are produced, which leads to the complexity of the system and the difficulty of maintenance. Readers in the adoption of Dimitri law need to weigh repeatedly, not only to make the structure clear, but also to achieve high cohesion and low coupling.
---> Dimitri Law requires decoupling between classes, but the decoupling is limited, the principle is only for reference, if it violates this principle, the project may not fail, which requires you to use the principle of repeated measures, do not follow is not correct, strict implementation is "too bad."



Iv.: Central idea
(1) in a scene, the A,b,c class. Complete a goal. A relies on b,b to rely on C, does not rely on repetition (the teacher lets the sports Commissioner statistics the scene), achieves the least kind of communication. Reduce the coupling between class classes
(2) The public method and property that the dependent class exposes the least to the dependent class.
(3) Once the coupling degree decreases, the jump is more. If you consider the principle, you cannot make the call layer too much.

Six design principles of Zen design pattern-Dimitri principles