First, the Primer
Ten years ago, there was an upstart who had three cars---Mercedes-Benz, BMW BMW, Audi Benz, and hired a driver to help him drive. But the nouveau riche is always a strange ride: After the Benz with the driver said "drive Mercedes!" "When he was in BMW, he said," Drive a BMW! "Take the Audi and say," Drive the car! ”。 You must say: this man is sick! Why don't you just say drive?!
And when we put this upstart's behavior into our programming, we find that this is a common phenomenon, and fortunately, this kind of illness can be avoided in OO (object-oriented) languages. The following is a Java language-based approach to introducing our theme: Factory mode.
Second, classification
Factory mode is primarily to provide an over-interface for creating objects so that the specific process of creating objects is masked for increased flexibility.
The factory model is divided into three categories in Java and mode:
1) Simple Factory mode
2) Factory method mode
3) Abstract Factory mode
These three modes are progressively abstracted from top to bottom and more general.
In design mode, GOF divides the factory model into two categories: The Factory method Model (Factory) and the Abstract Factory mode (abstraction Factory). The simple Factory is seen as a special case of the factory model, which is grouped into one category.
Three, simple Factory mode
The simple factory model is also called the Static factory method mode. Renaming can tell that this pattern must be simple. The purpose of its existence is simple: Define an interface for creating objects.
Let's take a look at its composition:
1) Factory class role: This is the core of this model, contains certain business logic and judgment logic. In Java it is often implemented by a specific class.
2) Abstract Product role: It is generally the product of the specific inheritance of the parent class or implementation of the interface. Implemented in Java by an interface or an abstract class.
3) Specific product roles: the object created by the factory class is an instance of this role. Implemented in Java by a concrete class.
To use a class diagram to clearly represent the relationship between them:
So how does the simple factory model work? We are using a simple factory model to transform the nouveau riche car-now the upstart just need to sit in the car and say to the driver: "Drive" on it.
Abstract product role public interface car{public void Drive (); Specific product roles public class Benz implements car{public Void Drive () { System.out.println ("Driving Benz");} } public class BMW implements car{public Void Drive () { System.out.println ("Driving Bmw"); }} ... (Audi I will not write: P)//factory class Role public class driver{ //factory method. Note The return type is abstract product role public static Car Drivercar (String s) throws Exception { //judgment logic, return the specific product role to client if (s.equalsignorecase ("Benz")) return new Benz (); else if (s.equalsignorecase ("BMW")) return new BMW (); ...... else throw new Exception ();.. Welcome to the nouveau riche ... public class magnate{public static void Main (string[] args) { try{ //Tell the driver I'm going to ride a Mercedes today. Car car = Driver.drivercar ("Benz"); Next command: Drive car.drive ();
The relationships of each class in the program are expressed as follows:
This is the simple factory model. How easy is it to use? So what benefits does it bring?
First, after using the simple factory model, our program is not "sick", more in line with the reality of the situation, and the client is exempt from the direct creation of product object responsibility, but only responsible for "consumption" products (as the upstart).
Below we analyze the Simple Factory mode from the opening and closing principle (open for expansion; closed for modification). When the upstart adds a car, as long as the contract is in line with the abstract product, then it can be used by the customer if the factory is informed. So for the part of the product, it is in line with the principle of open and closed, but the factory part seems to be not ideal, because each additional vehicle, in the factory class to add the corresponding business logic or judgment logic, which is clearly against the opening and closing principle. It can be imagined that the introduction of new products, factory class is very passive. For such a factory class (in our case
is for the driver master), we call it the Almighty or the God class.
Our example is the simplest case, and in practical applications it is possible that the product is a multi-layered tree structure. Since there is only one factory class in the simple factory model that corresponds to these products, this may be exhausting our God and exhausting our programmers: (So the factory method pattern appears as a savior.)
Four, factory method mode
The factory method pattern removes the static property of the factory method in the simple Factory mode, allowing it to inherit from the quilt class. The pressure to concentrate on factory methods in a simple factory model can be shared by different factory subclasses in the factory method model.
You should have roughly guessed the structure of the factory method pattern and look at its composition:
1) Abstract Factory role: This is the core of the factory method pattern, which is independent of the application. is the interface that the specific factory role must implement or the parent class that must inherit. In Java it is implemented by an abstract class or interface.
2) Specific factory role: it contains code related to the specific business logic. Called by the application to create an object that corresponds to a specific product.
3) Abstract Product role: It is the parent of a specific product inheritance or an interface implemented. In Java, there are generally abstract classes or interfaces to implement.
4) Specific product roles: the object created by the specific factory role is an instance of this role. Implemented in Java by a specific class.
Use a class diagram to clearly represent the relationship between them:
The factory method pattern uses multiple subclasses that inherit from the abstract factory role to replace the "God Class" in the simple factory pattern.
This, as mentioned above, shares the pressure on the object, and this makes the structure flexible--When a new product (ie, the upstart car) is produced, it can be used by the customer as long as it is generated by the contract provided by the abstract product role and the abstract factory role, without having to modify any existing code. We can see that the structure of the factory role is also in line with the closed principle!
Let's use a complete example to see how the various roles in the factory model are coordinated. In the words of the upstart business more and more, their car is more and more. This can be bitter the driver master, what car it must remember, maintenance, all must go through him to use! So the nouveau riche sympathy he said: "Look at you and me for so many years, you do not have to work so hard, I assign you a few staff, you just keep them in mind!" As a result, the management of the factory method pattern arose. The code is as follows:
Abstract product roles, specific product roles similar to the simple factory model, just become more complex, here slightly. Abstract Factory role public interface driver{public Car Drivercar ();} public class Benzdriver implements driver{public Car Drivercar () { return new Benz (); }} public class Bmwdriver implements driver{public Car Drivercar () { return new BMW (); }} should be the corresponding relationship with the specific products ...//Please Mr. Nouveau riche public class magnate{public static void Main (string[] args) { try{ Driver Driver = new Benzdriver (); Car car = Driver.drivercar (); Car.drive (); } ......}
It can be seen that the addition of the factory method increases the number of objects exponentially. When the product category is very long, there will be a large number of corresponding plant objects, which is not what we want. Because if this is not the case, consider using the simple factory model combined with the factory method pattern to reduce the factory class: That is, the simple factory pattern is used for similar species on the product tree (which is usually brothers in the leaves of the tree).
V. Summary
The factory method pattern seems to have been perfectly wrapped in the creation of objects, allowing the client to process only the interfaces provided by the abstract product role. Do we have to be in the code all over the factory? It doesn't have to be big. Perhaps you might consider using the factory method mode under the following conditions:
1) When the client program does not need to know the creation process to use the object.
2) The object used by the client is subject to change, or it is not known which specific object to use.
The simple Factory mode and factory method mode really avoids the code changes? No. In the simple factory model, a new product is added to modify the judgment statement in the factory role, while in the factory method mode either the judgment logic is left in the abstract factory role or the specific factory role is written to die in the client program (as in the example above). and the product
Changes to the object creation condition will inevitably cause changes in the factory role.
In the face of this, the ingenious combination of the reflection mechanism and the configuration file of Java breaks the limits-a perfect embodiment of spring.
VI. Abstract Factory mode
First come to know what is the product family: in the different product hierarchy structure, the function of the product group of related products. Let's use an example to illustrate it in a figurative way.
The Bmwcar and Benzcar in the figure are two product trees (product hierarchies), and Benzsportscar and Bmwsportscar are a product family. They can all be put into the sports car family, so the function is connected. Similarly Bmwbussinesscar and Benzsportscar are also a product family.
Back to the topic of abstract Factory mode.
It can be said that the difference between the abstract factory pattern and the factory method pattern is the complexity of the objects that need to be created. and the abstract factory model is the most abstract and most general of the three.
Abstract Factory mode is intended to provide an interface to the client to create product objects in multiple product families
Also, use the abstract Factory mode to meet the criteria:
1) There are multiple product families in the system, and the system may only consume one product at a time.
2) products belonging to the same product family for their use.
Take a look at the various roles of the abstract Factory model (as in the factory approach):
1) Abstract Factory role: This is the core of the factory method pattern, which is independent of the application. is the interface that the specific factory role must implement or the parent class that must inherit. In Java it is implemented by an abstract class or interface.
2) Specific factory role: it contains code related to the specific business logic. Called by the application to create an object that corresponds to a specific product. In Java it is implemented by a specific class.
3) Abstract Product role: It is the parent of a specific product inheritance or an interface implemented. In Java, there are generally abstract classes or interfaces to implement.
4) Specific product roles: the object created by the specific factory role is an instance of this role. Implemented in Java by a specific class.
The class diagram is as follows:
I have seen the first two patterns, the coordination between the various roles of this pattern should have a number of hearts, I will not cite specific examples. Just be sure to meet the criteria for using the abstract factory model.
The factory model of the design mode in a comprehensible way
