We have already introduced the simple Factory Pattern and Factory Method Pattern. Here we will continue to introduce the third factory pattern - Abstract Factory Pattern, again taking the manufacturing of cars as an example.
Example background:
As customers’ requirements become higher and higher, BMW cars require different configurations of air conditioners, engines and other accessories. So the factory began to produce air conditioners and engines for assembling cars. At this time, the factory has two series of products: air conditioners and engines. The BMW 320 series is equipped with model A air conditioner and model A engine, and the BMW 230 series is equipped with model B air conditioner and model B engine.
Concept:
The abstract factory pattern is an upgraded version of the factory method pattern. It is used to create a set of related or interdependent objects. For example, the BMW 320 series uses air conditioner model A and engine model A, while the BMW 230 series uses air conditioner model B and engine model B. Then using the abstract factory pattern, when producing related accessories for the 320 series, there is no need to specify the model of the accessory. It will Automatically produce the corresponding accessory model A according to the car model.
In view of the introduction to the abstract factory pattern on Baidu Encyclopedia, combined with this example:
When each abstract product has more than one specific subcategory (air conditioners have models A and B, and engines also have model A and B), how does the factory role know which subclass to instantiate? For example, each abstract product role has two specific products (product air conditioner has two specific products, air conditioner A and air conditioner B). The abstract factory pattern provides two specific factory roles (BMW 320 series factory and BMW 230 series factory), which correspond to these two specific product roles respectively. Each specific factory role is only responsible for the instantiation of a certain product role. Each concrete factory class is only responsible for creating instances of a specific subclass of the abstract product.
Abstract Factory Pattern Code
Product Category:
//发动机以及型号 public interface Engine { } public class EngineA extends Engine{ public EngineA(){ System.out.println("制造-->EngineA"); } } public class EngineBextends Engine{ public EngineB(){ System.out.println("制造-->EngineB"); } } //空调以及型号 public interface Aircondition { } public class AirconditionA extends Aircondition{ public AirconditionA(){ System.out.println("制造-->AirconditionA"); } } public class AirconditionB extends Aircondition{ public AirconditionB(){ System.out.println("制造-->AirconditionB"); } }
Create Factory Class:
//创建工厂的接口 public interface AbstractFactory { //制造发动机 public Engine createEngine(); //制造空调 public Aircondition createAircondition(); } //为宝马320系列生产配件 public class FactoryBMW320 implements AbstractFactory{ @Override public Engine createEngine() { return new EngineA(); } @Override public Aircondition createAircondition() { return new AirconditionA(); } } //宝马523系列 public class FactoryBMW523 implements AbstractFactory { @Override public Engine createEngine() { return new EngineB(); } @Override public Aircondition createAircondition() { return new AirconditionB(); } }
Customer:
public class Customer { public static void main(String[] args){ //生产宝马320系列配件 FactoryBMW320 factoryBMW320 = new FactoryBMW320(); factoryBMW320.createEngine(); factoryBMW320.createAircondition(); //生产宝马523系列配件 FactoryBMW523 factoryBMW523 = new FactoryBMW523(); factoryBMW320.createEngine(); factoryBMW320.createAircondition(); } }
Regarding the difference between Abstract Factory Pattern and Factory Method Pattern, I won’t go into details here. I feel like reading the examples several times You can understand it, but there are many mentioned concepts such as product family and hierarchical structure, which are even more difficult to understand.
The origin of the abstract factory pattern
The following is a quote from the origin of the abstract factory pattern:
The origin or earliest application of the abstract factory pattern is used to create window structures belonging to different operating systems. For example: the command button (Button) and the text box (Text) are both window structures. In the window environment of the UNIX operating system and the window environment of the Windows operating system, these two structures have different local implementations, and their details are different. .
In every operating system, there is a build family consisting of window builds. Here is the product family composed of Button and Text. Each window component forms its own hierarchical structure, with an abstract role giving an abstract functional description, and concrete subclasses giving specific implementations under different operating systems.
You can find that in the product class diagram above, there are two product hierarchical structures, namely the Button hierarchical structure and the Text hierarchical structure. There are two product families at the same time, namely the UNIX product family and the Windows product family. The UNIX product family consists of UNIX Button and UNIX Text products; the Windows product family consists of Windows Button and Windows Text products.
The system’s creation requirements for product objects are met by a project’s hierarchical structure, in which there are two specific project roles, namely UnixFactory and WindowsFactory. The UnixFactory object is responsible for creating products in the Unix product family, while the WindowsFactory object is responsible for creating products in the Windows product family. This is the application of the abstract factory pattern. The solution of the abstract factory pattern is as follows:
Obviously, a system can only run in the window environment of a certain operating system, and cannot run on different operating systems at the same time. Therefore, the system can actually only consume products belonging to the same product family.
In modern applications, the scope of use of the abstract factory pattern has been greatly expanded, and the system is no longer required to consume only a certain product family.
Summary:
Whether it is a simple factory pattern, a factory method pattern, or an abstract factory pattern, they all belong to the factory pattern and are very similar in form and characteristics. Their ultimate goal is to decouple. When using it, we don't have to worry about whether this pattern is a factory method pattern or an abstract factory pattern, because the evolution between them is often confusing. Often you will find that when new requirements come and a new method is added to the factory method pattern that is clearly used, it becomes the abstract factory pattern because the products in the class constitute product families in different hierarchical structures. For the abstract factory pattern, when one method is reduced so that the provided products no longer constitute a product family, it evolves into the factory method pattern.
So, when using the factory pattern, you only need to care about whether the purpose of reducing coupling is achieved.
For more articles related to the Abstract Factory Pattern of JAVA design patterns, please pay attention to the PHP Chinese website!
Related articles:
Detailed explanation of the specific code to implement the abstract factory pattern in Java
Comparison of PHP simple factory pattern, factory method pattern and abstract factory pattern