Analysis of Java design pattern (II.)

2. Richter Replacement principle:LSP(Liskov Substitution Principle) richter substitution principle, defined as long as the parent class appears where the subclass can appear, and after the subclass is replaced, There is no problem with the program, and the user does not care whether it is a parent class or a subclass. This is also a manifestation of our Java inheritance feature.

The following is a practical project encountered a simple requirement: Now there is a class A product needs to call METHOD1 (), Class B products also need to call method (), the same class C products also need to call method (), But we need to let D this person deal with this method (), then we can design an abstract class ABSTRACTB (or interface).

The ABSTRACTB class code is as follows:

1  Public Abstract class ABSTRACTB {2          // Implementing Logic 3      Public Abstract void Method (); 4 }

The following a,b,c classes inherit the abstract class ABSTRACTB, respectively:

 1  public  class  A extends   ABSTRACTB { 2  3   @Override  4  public  void   Method () { 5  System.out.println ("A implementation Method ...." ); 6   7  8 } 

 Public class extends ABSTRACTB {        @Override    publicvoid  Method () {        System.out.println (" b Implement method .... ");    }    }

 Public class extends ABSTRACTB {        @Override    publicvoid  Method () {        System.out.println ("C implementation method .....");}    }

Design Class D

1@SuppressWarnings ("Unused")2  Public classD {3 4      PublicABSTRACTB abstractobj;5     6      Public voidsetrealobj (Abstractb realobj) {7          This. Abstractobj =abstractobj;8     }9     Ten      Public voidInvocatemethod () { One         //Method Invocation A Abstractobj.method (); -     } -}

Note: When invoking other class objects in a class, the parent class or interface must be used, and if not, the LSP principle is violated.

Write a test class:

1  Public classTest {2 3      Public Static voidMain (string[] aa) {4D d =NewD ();5D.setrealobj (NewA ());6         /*d.setrealobj (New B ());7 d.setrealobj (New C ());*/8 D.invocatemethod ();9     }Ten  One}

In the Setrealobj method above, a subclass entity is passed, which is the parent class type, where we do not care whether the parent class or the subclass is passed. Conversely, if the parameter type is a subclass, the type of the parent class passed is not necessarily applicable. Contrary to the principle of replacing the Richter scale, if there is an E product that also needs to implement method methods, it is only possible to implement abstract class ABSTRACTB.

The purpose of the Richter replacement principle is to enhance the robustness of the program and facilitate the compatibility of the system. Adding subclasses in a timely manner can also be good enough to continue execution.

3. Dependence reversal Principle: DIP (dependence inversion Principle) This is the basis of the open and close principle, specific content: interface-oriented programming (OOD), dependent on the abstract and not dependent on the specific, when used to specific classes, do not interact with specific classes, and specific classes of the upper interface or abstract class interaction .

This is actually quite similar to the LSP. is to interact with the upper layer as much as possible. Look at the code and talk.

For example, drivers drive cars, cars have BMW, there are Mercedes, there are other models of cars.

Fix a driver interface driver

1  Public Interface idriver {2      Public void Drive (); // Drive 3 }

Define an automobile interface car

1  Public Interface ICar {2      Public void run (); // Car Run 3 }

Define BMW, Mercedes-Benz to achieve automotive interface

 1  public  class  Benz implements   ICar { 2  3   @Override  4  public  void   run () { 5  System.out.println ("Mercedes run up ...." ); 6   7  8 } 

 Public class Implements ICar {    @Override    publicvoid  run () {        System.out.println ("BMW runs up .... ");    }
}

To implement the driver interface:

   Public class Implements Idriver {       public  ICar car;       // this is where the dependent object      is passed by constructor  Public Driver (ICar _car) {         this. Car= _car;      }       @Override       publicvoid Drive () {         this. Car.run ();      }} 

There are two other ways of implementing dependency injection. Seter method injection, interface declaration delivery.

The nature of dependency inversion is to implement each class or module independently of each other through an abstract class or interface to achieve loose coupling between modules. We try to follow the following points:

First: Each class has an interface or abstract class or both.

Second: The surface type of the variable is as far as the interface or abstract class.

Third: Try not to concrete class derivation, try not to replicate the method of the base class.

Four: The use of the Richter replacement principle. The personal feeling of the two is actually very much the same in meaning.

In layman's terms, the concept of inversion, I think, is to use abstraction instead of detail, which is inverted.

Continuous update ...

Analysis of Java design pattern (II.)