Main excerpt: http://blog.csdn.net/zhangerqing/article/details/8194653
Six principles of design patterns
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.
First, the factory model
1. The Common Factory model is the creation of a factory class that creates instances of classes that implement the same interface.
Create an interface:
Public Interface Sender { publicvoid Send ();}
Second, create the implementation class:
Mailsender.java
Public class Implements sender{ @Override publicvoid Send () { // TODO auto-generated Method stub System.out.println ("MailSender");} }
Smssender.java
Public class Implements Sender { @Override publicvoid Send () { // TODO auto-generated method Stub System.out.println ("Smssender");} }
To create a factory class:
Public classSendfactory { PublicSender Produce (String type) {if("Mail". Equals (Type) { return NewMailSender (); } Else if("SMS". Equals (Type) { return NewSmssender (); } Else return NULL; } }
Test class:
Public class factorytest { publicstaticvoid main (string[] args) { new sendfactory (); = Sendfactory.produce ("Mail"); Sender. Send ();} }
2. multiple factory method modes . is an improvement to the common factory method pattern, in the normal factory method pattern, if the passed string is faulted, the object cannot be created correctly, and multiple factory method patterns provide multiple factory methods to create the objects individually.
To change the Sendfactory class:
Public class sendfactory { public Sender producemailsender () { returnNew MailSender (); } Public Sender Producesmssender () { returnnew smssender (); }}
Test:
Public class factorytest { publicstaticvoid main (string[] args) { new sendfactory (); = Sendfactory.producemailsender (); Sender. Send ();} }
3. static Factory method mode , the method in the above multiple factory method is set to static, do not need to create an instance, call directly.
To change the Sendfactory class:
Public class sendfactory { publicstatic Sender Producemailsender () { Returnnew MailSender (); } Public Static Sender Producesmssender () { returnnew smssender (); }}
Test class:
Public class factorytest { publicstaticvoid main (string[] args) { = Sendfactory.producemailsender (); Sender. Send ();} }
Second, 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.
Implementing the interface:
Public Interface Sender { publicvoid Send ();}
Two implementation classes:
Mailsender.java
Public class Implements sender{ @Override publicvoid Send () { // TODO auto-generated Method stub System.out.println ("MailSender");} }
Smssender.java
Public class Implements Sender { @Override publicvoid Send () { // TODO auto-generated method Stub System.out.println ("Smssender");} }
Two factory classes:
Sendsmsfactory.java
Public class Implements provider{ @Override public Sender Produce () { // TODO auto-generated method Stub returnnew smssender ();} }
Sendmailfactory.java
Public class Implements provider{ @Override public Sender Produce () { // TODO auto-generated method Stub returnnew MailSender ();} }
To implement an interface again:
Public Interface Provider { public Sender Produce (); }
Test class:
Public class factorytest { publicstaticvoid main (string[] args) { new sendsmsfactory (); = provider.produce (); Sender. Send ();} }
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.
Public classSingleton {/*holds private static instances, prevents references, and assigns null here to enable lazy loading*/ Private StaticSingleton instance =NULL; /*Private constructor method to prevent instantiation*/ PrivateSingleton () {}/*Static engineering methods, creating instances*/ Public StaticSingleton getinstance () {if(Instance = =NULL) {instance=NewSingleton (); } returninstance; } /*if the object is used for serialization, you can ensure that the object remains consistent before and after serialization*/ PublicObject readresolve () {returninstance; }}
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 () { ifnull) { new Singleton (); } return instance; }
Java Design Patterns