Abstract Factory pattern (Abstract Factory) is a common software design pattern. This pattern provides a unified creation interface for a product family. When a certain series of this product family is needed, a specific factory class can be created for this series of product families.
【Intention】
The abstract factory pattern provides an interface for creating system-related or interdependent objects without specifying their concrete classes [GOF95]
[Abstract Factory Pattern Structure Diagram]
[Main role in the abstract factory pattern]
Abstract Factory role: It declares an interface for creating abstract product objects. Usually implemented as an interface or abstract class, all concrete factory classes must implement this interface or inherit this class.
Concrete Factory role: implements the operation of creating product objects. The client calls this role directly to create an instance of the product. This role contains the logic for selecting appropriate product objects. Usually implemented using concrete classes.
Abstract Product role: declares the interface of a type of product. It is the parent class of objects created by the factory method pattern, or the interface they share.
Concrete Product role: Implement the interface defined by the abstract product role and define a product object that will be created by the corresponding concrete factory. It contains the business logic of the application.
[Advantages and Disadvantages of Abstract Factory Pattern]
Advantages of the abstract factory pattern:
1. Separate specific classes
2. Make it easy to add or replace product families
3. Conducive to product consistency
Disadvantages of the abstract factory pattern: It is difficult to support new types of products. This is because the AbstractFactory interface determines the collection of products that can be created. Supporting new types of products requires extending the factory access interface, resulting in changes to the AbstractFactory class and all its subclasses.
The abstract factory supports the addition of new products in an oblique manner. It provides convenience for the addition of new product families, but cannot provide such convenience for the addition of new product hierarchical structures.
[Applicable Scenarios of Abstract Factory Pattern]
The abstract factory pattern should be used in the following situations:
1. A system should not depend on the details of how product class instances are created, combined, and expressed. This is important for all forms of factory patterns.
2. The products of this system have more than one product family, and the system only consumes products from one of the families.
3. Products belonging to the same product family are used together, and this constraint must be reflected in the system design.
4. The system provides a product class library, and all products appear with the same interface, so using the client does not depend on the implementation
【Java and Patterns Page 189】
Several key points of Abstract Factory mode:
1. If there is no need to cope with the demand changes of "multi-series object construction", there is no need to use the Abstract Factory mode.
2. "Series objects" refers to the interdependence or interaction between objects.
3. The Abstract Factory model is mainly designed to respond to changes in demand for “new series”. The disadvantage is that it is difficult to deal with
Changes in demand for "new objects". This should be noted, as mentioned before, if we want to join now
For other series of classes, code changes will be huge.
4. Abstract Factory mode is often combined with Factory Method mode to deal with
Changes in requirements for "object creation".
Addition in abstract factory
1. When the number of product hierarchical structures remains unchanged, adding a new product family means adding one (or more) new concrete (or abstract and concrete) products to each product hierarchical structure. Role. Since the factory level structure is a registration organization parallel to the product level structure, when the product level structure is adjusted, the factory level structure needs to be adjusted accordingly. Now that new elements have appeared in the product hierarchy, it is necessary to add corresponding new elements to the factory hierarchy. In other words, designers only need to add new specific factory classes to the system, and there is no need to modify existing factory roles or product roles. Therefore, when the product family in the system increases, the abstract factory pattern supports the "open-close" principle.
2. Add a new product level structure while the number of product families remains unchanged. In other words, the number of products in all product classes does not change, but there is now a new product class parallel to the existing product class. To do this, you need to modify all factory roles and add a new factory method to each factory class, which obviously violates the "open-close" principle. In other words, for the increase in product hierarchical structure, the abstract factory pattern does not support the "open-close" principle.
Taken together, we can know that adding concrete products to existing abstract products supports the "open-closed principle", but adding abstract products does not support the "open-closed" principle. The abstract factory pattern supports the addition of new products in an oblique manner. It provides convenience for the addition of new product families, but cannot provide such convenience for the addition of new product hierarchical structures.
[Abstract factory pattern and other patterns]
Singleton mode: A specific factory class can be designed as a singleton class. Since one factory usually suffices, specific factory subclasses are generally implemented as a Singleton.
Factory method pattern: The method of creating products in an abstract factory is defined as a factory method.
Prototype mode: If there are multiple possible product series, a specific factory can also use the prototype mode, and the specific factory uses the product series.
Each product prototype is instantiated and new products are created by copying its prototype.
[Abstract Factory Pattern PHP Example]
Factory method pattern:
An abstract product class can derive multiple specific product classes.
An abstract factory class can derive multiple concrete factory classes.
Each concrete factory class can only create one instance of a concrete product class.
Abstract factory pattern:
Multiple abstract product classes, each abstract product class can derive multiple specific product classes.
An abstract factory class can derive multiple concrete factory classes.
Each concrete factory class can create multiple instances of concrete product classes.
Difference:
The factory method pattern has only one abstract product class, while the abstract factory pattern has multiple.
The concrete factory class of the factory method pattern can only create one instance of the specific product class, while the abstract factory pattern can create multiple instances.
Abstract Factory: It is deeper than the factory pattern. This time, even the implementation class of the factory is not known. Different people can get different factory classes. So the abstract factory class is actually a factory class that can produce different factory classes.
To put it simply, if the relationship "generating objects with a factory" is regarded as a first-level generation relationship, then the abstract factory method is a factory method with a second-level generation relationship. If the actual environment is more complex, it can be level 3 or even level 4, so don’t think too complicated, it’s that simple.
This book on Design Patterns is well written, but please read it for inspiration and don’t delve into it, because:
Earlier when Design Patterns was written, programmers’ understanding of programs was as long as the code could be compiled and passed. So you will find that there are many features that seem idiotic now. It goes without saying that we usually use them this way. This is because you are looking at the products of the Stone Age from the industrial age, so you don’t have to use certain modes
Design patterns are not specific to the Java language, so you won’t be able to use some features at all
The situations you encounter in actual work are far simpler than those mentioned in design patterns, and some patterns are so useless that you won’t be able to use them at all. There is no need to delve into it
The best way to read this book is to read it quickly. It doesn’t mean you should skip reading, but you should read it patiently. Just don’t get into trouble, read it normally and don’t stop. You won’t be that awesome after reading this, but after a few years of development work, it will naturally make sense if you look back and see that there are many things you don’t understand. In the future development process, you will occasionally have questions about your code writing process. Some inspiration.