Java design Pattern-Basic thought Summary 1

Look at the design pattern of related books also for a period of time, the beginning is actually holding as Java three framework of the basic knowledge of the reserve to learn, but later, only to find that in the design pattern of some criteria decoration, Java object-oriented power is really reflected, The following will be summed up in the design pattern learning process of some of the experience, this is a personal understanding of the design pattern of some of the core ideas of a simple summary, but also I think in the design mode of the core part of the idea.

First, the design attempt of software engineering

Some requirements of software engineering. In software engineering, the most basic requirements are reusable rows and extensibility, the former requires that the system design at the code level can have a good organizational structure so that the public code can write the export calls at once, the latter requires the software system in the upgrade maintenance can not affect the previously encoded module, Scalability requires that we increase the code to achieve extensibility rather than modify the code (after all, the change increases the risk of a bug).

And the above requirements of software system, so that we design the software module to have the final two properties: high cohesion and low coupling, the former explained that the module function as far as possible to rely on their own internal completion, the module itself can be maximized to achieve their original function; low coupling and high cohesion actually mean almost, just change an algorithm, It requires that the links between modules be minimized as much as possible.

　

Ii. Encapsulation of objects

When it comes to object-oriented, there may be no systematic thinking or learning about design patterns. The first impression is: object-oriented = Encapsulation class. Indeed, I used to be so superficial that the object-oriented, is not to be a pair of related variables and methods, packaged into an ADT, that is, a class in Java to reuse it, when needed to call the appropriate method of the new object is not on the line, the package seems to have solved a lot of problems.

Indeed, encapsulation provides us with a code reuse and an object-oriented abstraction to organize our program structure, which allows us to have efficient means of organizing programs. However, many times, the nature of the package alone is not able to meet the requirements of the software design of high cohesion low coupling, specific examples are followed by examples.

Iii. for abstract programming

1. Manipulate objects with the parent class reference.

As stated earlier, the encapsulation of objects does not solve the extensibility problem of software engineering, the following example does not meet the requirements of software engineering:

//There is an animal classclassanimal{//it has various propertiesString height =NULL; String Foot=NULL; //.... Other Properties//There are some ways     Public voidrun () {System.out.println ("Animal Run Method"); }     Public voideat () {System.out.println ("Animal Eat Method"); }}//Here's a cat that inherits the animal classclassCatextendsanimal{//overriding the parent class method     Public voidrun () {System.out.println ("Cat Run Method"); }}//is a test classclasstest{ Public voidTest () {cat cat=NewCat (); Cat.run ();//Obviously, this can call the cat's Run method    }}

To observe the code, in the test method, it has the following areas to optimize:

A, Cat.run does not show too much of the role of the parent class, it simply calls its own object reference to execute the method, when I want to execute the other animal's Run method in the test method, I have to re-write a special set for an animal test method, did not achieve the purpose of reusing code;

B, in addition, if at some point the animal in the test method is not cat (for example, I suddenly do not want to have a cat and replaced by a dog), then also need to change hard coding (of course, you can use a method to create a specific test method)

C, this code does not reflect an object-oriented a very important nature: polymorphism. Now that the subclass can perform a run rewrite, the same method of showing the different subclasses in the code will behave differently.

(Well, in fact, these three points is a point: The code is not extensible, does not reflect polymorphism)

The following is a simple rewrite (just rewrite the test Class):

 //  This is a rewritten test class   Class   test{Animal Animal  = null     Span style= "COLOR: #000000" >;  //  add a constructor  public   Test (Animal Animal) { this<    /span>.animal = animal;  public  void   Test () { //     Span style= "COLOR: #000000" > Animal.run (); }}

The rewritten code has a high degree of cohesion, because the test class itself does not depend on any other animal, and if you want to perform a cat corresponding method on the test method, pass in the Cat object directly in the constructor, and you need to pass the dog into the dog. The polymorphic nature of Java automatically helps you complete specific run methods based on specific classes! Obviously, this test class has become the basic requirement of software engineering: high cohesion (just rely on internal code to do the corresponding operation), low coupling (not dependent on a particular object, just rely on the abstract level of animal)

So you can summarize this: manipulating the parent class's reference to control the operation of the subclass object can achieve a polymorphic effect.

2, through the interface Operation object. Look at the following example:

//defines an interface that abstracts a behavior: FlyInterfaceflyaction{ Public voidfly ();}//Bird ClassclassBirdextendsAnimalImplementsflyaction{//implementing Interfaces     Public voidFly () {System.out.println ("I am Bird, this is my fly METHD"); }}//Duck ClassclassDuckextendsAnimalImplementsflyaction{ Public voidFly () {System.out.println ("I am Duck, this is my fly METHD"); }}//Similarly, we create a new test classclasstest{flyaction animalflyaction=NULL;  PublicTest (flyaction animalflyaction) { This. animalflyaction =animalflyaction; }     Public voidTest () {animalflyaction.fly (); }}

The code is simpler, and I'm mainly passing some ideas from the code:

A, why is fly defined as an interface, instead of adding a fly method directly in animal?

Because not all animal will fly, the code in animal must ensure that all subclasses are common. From this, we can probably realize some differences between implementing interface and class inheritance: The former is the extension of specific behavior, and the latter is the extraction and abstraction of public behavior.

B, the advantages of interface operation objects: Obviously, with the above discussion of the parent class reference operation subclass object, we can realize that the interface operation object is similar: Through the Java polymorphism mechanism to implement the specific implementation of the same method of the call, and the implementation of the method is not the same, Thus, the effect of cohesion poly-low coupling is achieved (also the effect of polymorphism).

Iv. Summary

So, with the example above, we could probably be programming for interface-oriented programming, or referring to parent-class referencing (in fact, more appropriately, for abstract programming, However, after the concept of the blog to explain the details of a general understanding: in fact, through the parent class reference to manipulate the subclass object or through the interface reference operation corresponding implementation class for code decoupling and polymorphic implementation.

So, we can draw a design principle one:

Try to make use of the parent class reference and interface for the object's specific operation.

OK, the first part of the design pattern is here, and the blog behind it is a bit more in-depth thinking-oriented toward abstract programming and the means of packaging change.

Java design Pattern-Basic thought Summary 1