Design mode 1

Design mode (Patterns)

--the basis of reusable object-oriented software

Design patterns are a set of reusable, most known, categorized purposes, code design experience Summary. Design patterns are used in order to reuse code, make code easier for others to understand, and ensure code reliability. There is no doubt that design patterns in others in the system are multi-win, design patterns so that code is truly engineering, design patterns are the cornerstone of software engineering, like a block of bricks and tiles in the building. The rational use of design patterns in the project can solve many problems perfectly, each of which has corresponding principles in the present, each of which describes a recurring problem around us, and the core solution of the problem, which is why it can be widely used. This chapter is the beauty of Java [from rookie to master evolution] series of design patterns, we will be a combination of theory and practice in this chapter of the study, hope that the vast number of process enthusiasts, learn the design model, do a good software engineer!

I. Classification of design Patterns

In general, design patterns fall into three broad categories:

Create five types of models: Factory method mode, abstract Factory mode, singleton mode, builder mode, prototype mode.

Structure mode, a total of seven kinds: Adapter mode, adorner mode, proxy mode, appearance mode, bridging mode, combined mode, enjoy the meta-mode.

There are 11 types of behavioral Patterns: Strategy mode, template method mode, observer mode, iteration sub-mode, responsibility chain mode, Command mode, Memo mode, state mode, visitor mode, mediator mode, interpreter mode.

In fact, there are two types: concurrency mode and thread pool mode. Use a picture to describe it as a whole:

The six principles of design pattern

1. Opening and closing principle (Open Close Principle)

The open and closed principle is to say to the expansion opening, to modify the closure . When the program needs to expand, can not modify the original code, to achieve a hot plug effect. So a nutshell is: In order to make the program good extensibility, easy to maintain and upgrade. To achieve this, we need to use interfaces and abstract classes, which we will refer to later in the specific design.

2. The principle of substitution on the Richter scale (Liskov Substitution Principle)

One of the fundamental principles of object-oriented design of the Richter substitution principle (Liskov Substitution Principle LSP). The Richter substitution principle says that where any base class can appear, subclasses must be able to appear. LSP is the cornerstone of inheritance reuse, only if the derived class can replace the base class, the function of the Software unit is not affected, the base class can be really reused, and the derived class can also add new behavior on the basis of the base class. The principle of substitution on the Richter scale is a supplement to the principle of "open-closed". The key step in implementing the "open-close" principle is abstraction. The inheritance of the base class and subclass is the concrete implementation of abstraction, so the principle of the substitution of the Richter scale is the specification of the concrete steps to realize the abstraction. --from Baidu Encyclopedia

3. Dependence reversal principle (dependence inversion Principle)

This is the basis of the open and close principle, the specific content: TRUE interface programming, relying on abstraction and not dependent on the specific.

4. Interface Isolation principle (Interface segregation Principle)

This principle means that using multiple isolated interfaces is better than using a single interface. or a reduction of the coupling between the class meaning, from here we see, in fact, the design pattern is a software design ideas, from the large software architecture, in order to upgrade and maintenance convenience. So there are multiple occurrences: reducing dependency and reducing coupling.

5, Dimitri Law (least known principle) (Demeter Principle)

Why is it called the least known principle, that is to say: an entity should be as small as possible interaction with other entities, so that the system function module is relatively independent.

6. Synthetic multiplexing principles (Composite reuse Principle)

The principle is to use composition/aggregation as much as possible, rather than using inheritance.

Third, Java 23 design mode

Starting from this piece, we introduce in detail the concepts of 23 design Patterns in Java, application scenarios and other situations, and combine their characteristics and design patterns to analyze the principles.

1. Factory method Mode (Factory methods)

The factory method pattern is divided into three types:

11, the Common factory model , is to establish a factory class, the implementation of the same interface for some classes to create instances. First look at the diagram:

Here's an example: (Let's give an example of sending an email and a text message)

First, create a common interface for both:

Public interface Sender {public void Send ();}

Second, create the implementation class:

public class MailSender implements Sender {@Overridepublic void Send () {System.out.println ("This is mailsender!");}}

public class Smssender implements Sender {@Overridepublic void Send () {System.out.println ("This is SMS Sender!");}}

Finally, build the factory class:

public class Sendfactory {public Sender produce (String type) {if ("Mail". Equals (Type)} {return new MailSender ();} else if ("SMS". Equals (Type)) {return new Smssender ();} else {System.out.println ("Please enter the correct type!"); return null;}}}

Let's test it out:

public class Factorytest {public static void main (string[] args) {Sendfactory factory = new Sendfactory (); Sender sender = factory.produce ("sms"); sender. Send ();}}

Output: This is SMS sender!

22, multiple factory method mode , is the improvement of the common factory method mode, in the normal factory method mode, if the passed string error, the object cannot be created correctly, and the multiple factory method pattern is to provide multiple factory methods, create the object respectively. Diagram:

Make the above code changes, change the next Sendfactory class on the line, as follows:

public class Sendfactory {public Sender producemail () {return new MailSender ();} Public Sender producesms () {return new Smssender ();}}

The test classes are as follows:

public class Factorytest {public static void main (string[] args) {Sendfactory factory = new Sendfactory (); Sender sender = Factory.producemail (); sender. Send ();}}

Output: This is mailsender!

33, Static Factory method mode , the above method of multiple factory methods to static, do not need to create an instance, directly call.

public class Sendfactory {public static Sender Producemail () {return new MailSender ();} public static Sender Producesms () {return new Smssender ();}}

public class Factorytest {public static void main (string[] args) {Sender sender = Sendfactory.producemail (); sender. Send ();}}

Output: This is mailsender!

In general, the factory model is suitable: when a large number of products need to be created, and have a common interface, can be created through the factory method mode. In the above three modes, the first if the incoming string is wrong, the object is not created correctly, the third is relative to the second, do not need to instance the chemical plant class, so, in most cases, we will choose the third-static factory method mode.

2. Abstract Factory mode (Factory)

The problem with factory method mode is that class creation relies on the factory class, that is, if you want to expand the program, the factory class must be modified, which violates the closure principle, so from the design point of view, there are certain problems, how to solve? Use the abstract factory pattern to create multiple factory classes so that once you need to add new functionality, you can add new factory classes directly, without having to modify the previous code. Because the abstract factory is not very well understood, we first look at the diagram, and then the code, it is more easily understood.

Take a look at the example:

Public interface Sender {public void Send ();}

Two implementation classes:

public class MailSender implements Sender {@Overridepublic void Send () {System.out.println ("This is mailsender!");}}

public class Smssender implements Sender {@Overridepublic void Send () {System.out.println ("This is SMS Sender!");}}

Two factory classes:

public class Sendmailfactory implements Provider {@Overridepublic Sender produce () {return new MailSender ();}}

public class Sendsmsfactory implements provider{@Overridepublic Sender produce () {return new Smssender ();}}

In providing an interface:

Public interface Provider {public Sender produce ();}

Test class:

public class Test {public static void main (string[] args) {Provider Provider = new Sendmailfactory (); Sender sender = provider.produce (); sender. Send ();}}

In fact, the advantage of this model is that if you want to add a function now: Send timely information, you just need to do an implementation class, to implement the sender interface, at the same time do a factory class, implement Provider interface, OK, no need to change the ready-made code. To do so, expand better!

3. Single case mode (Singleton)

A singleton object (Singleton) is a common design pattern. In Java applications, singleton objects guarantee that only one instance of the object exists in a JVM. There are several benefits to this model:

1, some classes are created more frequently, for some large objects, this is a lot of overhead.

2, eliminate the new operator, reduce the use of system memory frequency, reduce the GC pressure.

3, some classes such as the exchange's core trading engine, control the trading process, if the class can create multiple words, the system is completely chaotic. (for example, an army has multiple commanders at the same time command, it will certainly mess), so only using a singleton mode can ensure that the core trading server independently control the entire process.

First, let's write a simple singleton class:

public class Singleton {/* * holds private static instances, prevents references, and is assigned null here to implement lazy loading */private static Singleton instance = null;/* Private construction method to prevent instantiation */private Singleton () {}/* static engineering method, creating instance */public static Singleton getinstance () {if (instance = null) {instance = new Sin Gleton ();} return instance;} /* If the object is used for serialization, you can ensure that the object remains consistent before and after serialization */public object Readresolve () {return instance;}}

This class can meet the basic requirements, but, like this no thread-safe class, if we put it into multi-threaded environment, there will be problems, how to solve? We will first think of the GetInstance method plus the Synchronized keyword, as follows:

public static synchronized Singleton getinstance () {if (instance = = null) {instance = new Singleton ();} return instance;}

However, the Synchronized keyword lock is the object, such usage, will be degraded in performance, because each call to getinstance (), the object must be locked, in fact, only when the first time the object is created to lock, and then do not need, so, This place needs to be improved. Let's change to the following:

public static Singleton getinstance () {if (instance = = null) {synchronized (instance) {if (instance = = null) {instance = n EW Singleton ();}}} return instance;}

Seems to solve the problem mentioned earlier, the Synchronized keyword is added to the internal, that is, when the call is not required to lock, only when the instance is null, and create the object only need to lock, performance has a certain elevation. However, there may be problems with this, see the following: creating objects and assigning operations in Java directives is done separately, that is, instance = new Singleton (); The statement is executed in two steps. However, the JVM does not guarantee the sequencing of the two operations, which means that it is possible for the JVM to allocate space for the new singleton instance and then assign the value directly to the instance member before initializing the singleton instance. This can be a mistake, we take a, b two threads as an example:

A>a, B Threads Enter the first if judgment at the same time

B>a first enters the synchronized block, because instance is null, so it executes instance = new Singleton ();

C> because of the optimization mechanism inside the JVM, the JVM first draws some blank memory allocated to the singleton instance and assigns it to the instance member (note that the JVM does not start initializing the instance at this time), and a leaves the synchronized block.

D>b enters the synchronized block because instance is not NULL at this time, so it immediately leaves the synchronized block and returns the result to the program that called the method.

E> this time the B thread intends to use the singleton instance, but finds that it was not initialized, and the error occurred.

So the program is still possible error, in fact, the program is very complex in the process of operation, from this point we can see, especially in the writing multi-threaded environment of the program is more difficult, challenging. We have further optimized the program:

private static class singletonfactory{                 private static Singleton instance = new Singleton ();             }             public static Singleton getinstance () {                 return singletonfactory.instance;             

The reality is that the singleton pattern uses an internal class to maintain the implementation of the Singleton, and the mechanism inside the JVM guarantees that when a class is loaded, the loading process of the class is thread-mutually exclusive. So when we first call getinstance, the JVM can help us ensure that instance is created only once and that the memory assigned to instance is initialized so we don't have to worry about the problem. At the same time, the method only uses the mutex mechanism when the first call is made, which solves the low performance problem. This allows us to briefly summarize a perfect singleton pattern:

public class Singleton {/* Private construction method to prevent instantiation of */private Singleton () {}/* Use an inner class here to maintain a singleton */private static class Singletonfactory {private static Singleton instance = new Singleton ();} /* Get instance */public static Singleton getinstance () {return singletonfactory.instance;} /* If the object is used for serialization, you can ensure that the object remains consistent before and after serialization */public object Readresolve () {return getinstance ();}}

In fact, it is perfect, not necessarily, if an exception is thrown in the constructor, the instance will never be created and will be faulted. So, the very perfect thing is not, we can only according to the actual situation, choose the most suitable for their own application of the implementation of the scenario. Others do this: because we only need to synchronize when creating the class, it is also possible to create the Synchronized keyword separately, as long as the creation and getinstance () are created separately:

public class Singletontest {private static Singletontest instance = Null;private singletontest () {}private static Synchron ized void Syncinit () {if (instance = = null) {instance = new Singletontest ();}} public static Singletontest getinstance () {if (instance = = null) {Syncinit ();} return instance;}}

With performance in mind, the entire program only needs to create one instance at a time, so performance has no effect.

Supplement: Use Shadow instance to synchronize updates for properties of Singleton objects

public class Singletontest {private static singletontest instance = Null;private Vector properties = null;public vector ge Tproperties () {return properties;} Private Singletontest () {}private static synchronized void Syncinit () {if (instance = = null) {instance = new Singletontest ();}} public static Singletontest getinstance () {if (instance = = null) {Syncinit ();} return instance;} public void Updateproperties () {singletontest shadow = new Singletontest ();p roperties = Shadow.getproperties ();}}

Learning through a singleton pattern tells us:

1, the single-case model is simple to understand, but the specific implementation is still a certain degree of difficulty.

2, synchronized keyword lock is the object, in use, it must be used in the appropriate place (note the need to use the lock object and process, may not be the whole object and the whole process need to lock).

Here, the singleton mode has been basically finished, at the end, I suddenly think of another problem, is the use of static methods of the class, to achieve the effect of a single-case model, is also feasible, here are the differences?

First, a static class cannot implement an interface. (It's possible from a class point of view, but that destroys the static.) Because static modifiers are not allowed in the interface, they are non-static even if implemented

Second, a singleton can be delayed initialized, and static classes are typically initialized in the first load. Delay loading is because some classes are large, so lazy loading can help improve performance.

Again, a singleton class can be inherited, and his method can be overwritten. However, static class internal methods are static and cannot be overwritten.

Finally, the Singleton class is more flexible, after all, from the implementation is just a common Java class, as long as the basic needs of the singleton, you can do in the arbitrary implementation of some other functions, but static class does not. From the above summary, the basic can see the difference between the two, but, on the other hand, we finally realized that the singleton pattern, the interior is a static class to achieve, so, the two have a great correlation, but we consider the level of the problem is different. The combination of two ideas to create a perfect solution, just like HashMap using array + linked list to achieve the same, in fact, many things in life are so, alone with different methods to deal with problems, there are always advantages and disadvantages, the most perfect way is to combine the advantages of each method, to best solve the problem!

4. Builder mode

The factory class pattern provides the pattern of creating a single class, while the builder pattern is to centralize the various products to manage, to create composite objects, so-called composite objects that refer to a class that has different properties, in fact the builder pattern is the combination of the previous abstract factory pattern and the last Test. Let's look at the code:

As before, a sender interface, two implementation classes MailSender and Smssender. Finally, the Builder class is as follows:

public class Builder {private list<sender> List = new arraylist<sender> ();p ublic void Producemailsender (int c Ount) {for (int i=0; i<count; i++) {list.add (New MailSender ());}} public void Producesmssender (int. count) {for (int i=0; i<count; i++) {list.add (New Smssender ());}}}

Test class:

public class Test {public static void main (string[] args) {Builder builder = new Builder (); Builder.producemailsender (10);} }

From this point of view, the builder pattern integrates many functions into a class that can create more complex things. So the difference with the engineering model is that the factory model is concerned with creating a single product, while the builder pattern is concerned with creating a conforming object, multiple parts. Therefore, the choice of the factory model or the builder model depends on the actual situation.

5. Prototype mode (PROTOTYPE)

Although the prototype pattern is a pattern of creation, it has nothing to do with the engineering model, and the idea of the pattern is to copy and clone an object as a prototype, and create a new object similar to the original object. This summary will be explained by the copy of the object. In Java, the Copy object is implemented through clone (), and a prototype class is created first:

public class Prototype implements cloneable {public Object clone () throws Clonenotsupportedexception {Prototype proto = (P Rototype) Super.clone (); return proto;}}

Very simple, a prototype class, only need to implement the Cloneable interface, overwrite the Clone method, where the Clone method can be changed to any name, because the Cloneable interface is an empty interface, you can arbitrarily define the method name of the implementation class, such as Clonea or CLONEB, Because the focus here is Super.clone (), Super.clone () invokes the Clone () method of object, whereas in the object class, Clone () is native, and I'll do it in another article, The call to interpret native methods in Java is no longer a drill down here. Here, I'll take a look at the shallow copy and deep copy of the object, and first we need to understand the concept of deep, shallow copying of objects:

Shallow copy: After copying an object, the variables of the base data type are recreated, and the reference type, pointing to the original object.

Deep copy: After copying an object, both the base data type and the reference type are recreated. In short, deep replication is completely replicated, and shallow copying is not exhaustive.

Here, write an example of a depth copy:

public class Prototype implements Cloneable, Serializable {private static final long Serialversionuid = 1l;private String  String;private serializableobject obj;/* Shallow copy */public Object clone () throws Clonenotsupportedexception {Prototype proto = (Prototype) Super.clone (); return proto;}  /* Deep Copy */public Object Deepclone () throws IOException, ClassNotFoundException {/* Write binary Stream */bytearrayoutputstream BOS for current object = new Bytearrayoutputstream (); ObjectOutputStream oos = new ObjectOutputStream (BOS); Oos.writeobject (this);/* read out the new object produced by the binary stream */bytearrayinputstream bis = new Bytearrayinputstream (Bos.tobytearray ()); ObjectInputStream Ois ObjectInputStream (bis); return Ois.readobject ();} public string getString () {return string;} public void SetString (string string) {this.string = string;} Public Serializableobject Getobj () {return obj;} public void Setobj (Serializableobject obj) {this.obj = obj;}} Class Serializableobject implements Serializable {private static final long serialversionuid = 1L;}

To implement a deep copy, you need to read the binary input of the current object in the form of a stream, and then write out the object corresponding to the binary data.

Design mode 1