Six principles of design patterns (5) & mdash; the six principles of design patterns

Six principles of design patterns (5)-the six principles of design patterns

Definition:

An object should have a minimum understanding of other objects. The dimit rule is also known as the minimum Knowledge rule. It is called the Least Knowledge Principle (LKP) in English.

Personal Understanding:

The primary objective of the dimit rule is inter-class decoupling and weak coupling. Only when the class is weakly coupled can the reusability of the class be improved.

Problem:

The closer the relationship between classes, the higher the coupling between classes. When a class is changed, the greater the coupling degree, the greater the impact on the other class.

Solution:

Minimize the coupling between classes.

All those who are engaged in programming know that the general principle of software programming is low coupling and high cohesion. Only in this way can the code reuse rate be improved, which is exactly what the dimit rule requires. The dimit rule also has a simpler definition: To communicate with direct friends only. 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. Here, we call the class in member variables, method parameters, and method return values as a direct friend, while the class in local variables is not a direct friend. That is to say, it is better not to appear in the class as a local variable for a strange class.

Example:

The instructor (Teacher Class) issues commands to the group leader class. The team lead collects and outputs statistics on the number of girls (Gril class. The code that violates the Demeter rule is as follows:

Public class Girl {} public class GroubLeader {// public void CountGrilNumber (List <Girl> girlslist) {Console. writeLine ("the number of girls is" + girlslist. count) ;}} public class Teacher {public void Command (GroubLeader groubLeader) {var grilList = new List <Girl> (); // initialize the Girl List for (var I = 0; I <30; I ++) {grilList. add (new Girl ();} // notify the Sports Committee member to check the number of girls groubLeader. countGrilNumber (grilList);} class Client {static void Main (string [] args) {var teacher = new Teacher (); // The instructor issues the command teacher. command (new GroubLeader (); Console. readKey ();}}

In the above Code, the Teacher initializes the Gril List. The instructor directly operates the List of girls, which obviously does not comply with the general rules, but does not comply with the dimit rules. The normal order is that the Teacher issues commands to the team lead, the group leader counts the number of girls. Class relationships should be decoupled as much as possible to reduce their coupling. The improved method is to privatize a List <Gril> variable in GroupLeader, and pass the List <Gril> parameter when constructing the GroupLeader variable. This reduces the coupling between Gril and GroupLeader. The improved code is as follows:

Public class Girl {} public class GroubLeader {private readonly List <Girl> _ girList; public GroubLeader (List <Girl> girlList) {_ girList = girlList ;} // check for girls' work public void CountGrilNumber () {Console. writeLine ("the number of girls is" + _ girList. count) ;}} public class Teacher {public void Command (GroubLeader groubLeader) {// notify the Sports Committee member to check the number of girls. countGrilNumber () ;}} class Client {static void Main (string [] args) {var girlList = new List <Girl> (); // initialize the girls' list for (var I = 0; I <30; I ++) {girlList. add (new Girl ();} var teacher = new Teacher (); // The instructor issues the command teacher. command (new GroubLeader (girlList); Console. readKey ();}}

The above example simply illustrates the use of the dummit rule, which may be somewhat far-fetched. The key is to understand the meaning of an object so that we can keep less understanding of other objects.

What are the six principles of JAVA object-oriented?

1) Open-Close Principle (OCP): the Principle of Open-Close is that the design should have good support for expansion, while the modification should be strictly limited. This is the most important and abstract principle. Basically, the Reusable Software we call is developed based on this principle. Other principles also provide a path for its implementation.

(2) Liskov Substituition Principle (LSP), which is a strict Principle. The rule is that "the subclass must be able to replace the base class; otherwise, it should not be designed as its subclass ." That is to say, subclass can only extend the base class, rather than hiding or overwriting the base class.
3) Dependence Inversion Principle (DIP) depends on the switching Principle. "design depends on abstraction rather than concrete ". In other words, we should use abstraction to think about the design, rather than first dividing what classes I need, because these are specific. What are the benefits of doing so? Human thinking itself is actually very abstract. When we analyze the problem, we do not consider the details at once, but abstract the entire problem, therefore, abstract design is in line with human thinking. In addition, this principle will support OCP very well. Abstract-oriented design makes it possible for us to not rely too much on implementation, so that expansion becomes possible, this principle is also the cornerstone of another article Design by Contract.

4) Interface Segregation Principle (ISP), "dividing large interfaces into multiple small Interfaces", the benefits of doing so are obvious. I don't know if it is necessary to continue the description, in order to save space, in fact I just made a small summary of these principles, if you need more in-depth understanding of it, it is recommended to see "Java and mode", a masterpiece of MS MVP! Pai_^

5) Composition/Aggregation Reuse Principle (CARP), designers should first consider combination/Aggregation, rather than inheritance (because it is intuitive, the first impression is "oh, this is OO "). This is the so-called "Favor Composition over Inheritance". In practice, combination/aggregation will bring greater benefits than Inheritance, So priority should be given.

6) Law of Demeter or Least Knowlegde Principle (low level or LKP), the Demeter Principle or Least knowledge Principle, which was first formally applied in the Demeter system and therefore defined as the Demeter Law. It is about "one object should know as few other objects as possible ". That is, another rule about Loosely-Coupled.

AS3 briefly introduces the concepts of upward and downward Conversion

Go to Baidu to check the Li's replacement principle. This is one of the six major design principles of the design model.

Single responsibility, Lishi replacement (replacement), dependency inversion, interface isolation, meter rule, and open/closed Principle

Or simply put, you need to understand the unification of as3.0, the two branches, and event-driven

In a unified manner, all display objects belong to the flash. display. DisplayObject class.
It is divided into two major branches.
The first branch is flash. display. InteractiveObject (Interactive object) and non-interactive object.
The second branch is flash. display. DisplayObjectContainer (container object) and non-container object.

The use of up-to-Down conversion and Down conversion is common when using events.

For example

Mc. addEventListener (MouseEvent. CLICK, onClick_func );

Function onClick_func (_ evt: MouseEvent): void {
Var _ mc: MovieClip = _evt.tar get as MovieClip;
// In this event processing function, _evt.tar get as MovieClip uses the downward conversion to transfer
// Convert the flash. display. DisplayObject type to its subclass flash. display. MovieClip
}

Up Conversion

For example

Function setX (_ obj: DisplayObject): void {
_ Obj. x = 100;
}

The parameter of this function uses the DisplayObject of the parent class as the type, which indicates that the parameter passed in by calling this function can be a subclass of all displayobjects, such as MovieClip, SimpleButton, such as TextField (text box ).

The parent class of the subclass is applied based on the upward or downward conversion of interfaces.