PHP implements detailed explanation of the abstract factory mode in the design mode, and detailed description of the design mode

PHP implements detailed explanation of the abstract factory mode in the design mode, and detailed description of the design mode

Abstract Factory is a common software design pattern. This mode provides a unified creation interface for a product family. When you need a series of product families, you can create a specific factory class for these product families.

[Intention]

Abstract Factory mode provides an interface for creating system-related or mutually dependent objects without specifying their specific classes [GOF95]

[Abstract factory pattern structure diagram]

[Abstract The main role of the factory model]

Abstract Factory role: it declares an interface for creating Abstract product objects. It is usually implemented using an interface or abstract class. All factory classes must implement this interface or inherit this class.

Concrete Factory role: create a product object. The client directly calls this role to create a product instance. This badge contains the logic for selecting the right product object. It is usually implemented using a specific class.

Abstract Product role: Declares the interfaces of a Product. It is the parent class of the object created in the factory method mode, or the interfaces they share.

Concrete Product role: implements the interface defined by the abstract Product role and defines a Product object that will be created by a specific factory. It contains the business logic of the application.

[Abstract advantages and disadvantages of the factory model]

Advantages of the abstract factory model:
1. Separated specific classes
2. Make it easy to add or replace product families
3. conducive to product consistency

Disadvantages of the abstract factory model: It is difficult to support new types of products. This is because the AbstractFactory interface determines the product set that can be created. To support various new products, you need to extend the access factory interface, resulting in changes to the AbstractFactory class and all its subclasses.
Abstract Factory supports the addition of new products in a skewed manner. It facilitates the addition of new product families, rather than providing convenience for the addition of new product level structures.

[Application scenarios of abstract factory models]

The abstract factory model should be used in the following situations:
1. A system should not depend on the details of how product instances are created, combined, and expressed. This is important for all forms of factory models.
2. There are more than one product family in this system, and the system only consumes products of one of them.
3. products belonging to the same product family are used together. This constraint must be reflected in the system design.
4. The system provides a product library. All products use the same interface, so that the client does not rely on the implementation.
[Java and mode page 1]

Abstract Factory mode:

1. If the requirement for "Multi-series object building" is not changed, the Abstract Factory mode is not necessary.
2. "series object" refers to the relationship between objects that are mutually dependent or act.
3. The Abstract Factory mode mainly aims to cope with the changes in the needs of the new series. The disadvantage is that it is hard to cope
Requirement changes for "new object. This should be noted, as mentioned above, if we want to add
For other series of classes, the code will be greatly changed.
4. The Abstract Factory mode is often combined with the Factory Method mode.
Requirement changes for "Object creation.

Add in abstract factory

1. when the number of product level structures remains the same, adding a new product family means adding one or more products in each product level structure) new (or abstract and specific) Product roles. Because the factory level structure is a registration institution parallel to the product level structure, when the product level structure is adjusted, the factory level structure needs to be adjusted accordingly. Now there are new elements in the product level structure. Therefore, you need to add new elements to the factory level structure. In other words, the designer only needs to add a new factory class to the system, and there is no need to modify the existing factory role or product role. Therefore, when the product family in the system is increased, the abstract factory mode supports the "open-close" principle.

2. Add a new product level structure when the number of product families remains unchanged. In other words, the number of products in the product level structure will not change, but now there is a new product level structure parallel to the existing product level structure. To achieve this, we need to modify all the factory roles and add a new factory method to each factory class. This is obviously against the "open-close" principle. In other words, the abstract factory model does not support the "open-close" principle when the product level structure is increased.

In combination, we can know that adding specific products to existing abstract products supports the "open-close principle". However, when adding abstract products, it does not support the "open-close" principle. Abstract Factory mode supports the addition of new products in a skewed manner, which facilitates the addition of new product families, rather than facilitating the addition of new product level structures.

[Abstract Factory mode and other modes]

Singleton mode: a specific factory class can be designed as a Singleton class. Because a factory can usually have one, a specific factory subclass is generally implemented as a singleton.

Factory method mode: the method used to abstract a factory to create a product is defined as a factory method.

Prototype: if there are multiple possible product series, the specific factory can also use the prototype. The specific factory uses the product series.

The prototype of each product is instantiated and a new product is created by copying its prototype.

PHP example of abstract factory Mode]

Copy codeThe Code is as follows:
<? Php
/**
* Abstract factory model 2010-05-28 sz
* @ Author phppan. p # gmail.com
* @ Package design pattern
*/
 
/**
* Abstract Factory
*/
Interface AbstractFactory {
/**
* How to Create A factory for A product with A hierarchical structure of
*/
Public function createProductA ();
 
/**
* How to Create a factory for a product whose level structure is B
*/
Public function createProductB ();
 
}
 
/**
* Factory 1
*/
Class ConcreteFactory1 implements AbstractFactory {
 
Public function createProductA (){
Return new ProductA1 ();
}
 
Public function createProductB (){
Return new ProductB1 ();
}
}
 
 
/**
* Factory 2
*/
Class ConcreteFactory2 implements AbstractFactory {
 
Public function createProductA (){
Return new ProductA2 ();
}
 
Public function createProductB (){
Return new ProductB2 ();
}
}
 
/**
* Abstract product
*/
Interface AbstractProductA {
 
/**
* Get the product name
*/
Public function getName ();
}
 
/**
* Abstract product B
*/
Interface AbstractProductB {
 
/**
* Get the product name
*/
Public function getName ();
}
 
/**
* Specific product A1
*/
Class ProductA1 implements AbstractProductA {
Private $ _ name;
 
Public function _ construct (){
$ This-> _ name = 'produca1 ';
}
 
Public function getName (){
Return $ this-> _ name;
}
}
 
 
/**
* Product A2
*/
Class ProductA2 implements AbstractProductA {
Private $ _ name;
 
Public function _ construct (){
$ This-> _ name = 'product A2 ';
}
 
Public function getName (){
Return $ this-> _ name;
}
}
 
 
/**
* Product B1
*/
Class ProductB1 implements AbstractProductB {
Private $ _ name;
 
Public function _ construct (){
$ This-> _ name = 'product B1 ';
}
 
Public function getName (){
Return $ this-> _ name;
}
}
 
/**
* Product B2
*/
Class ProductB2 implements AbstractProductB {
Private $ _ name;
 
Public function _ construct (){
$ This-> _ name = 'product b2 ';
}
 
Public function getName (){
Return $ this-> _ name;
}
}
 
 
/**
* Client
*/
Class Client {
 
/**
* Main program.
*/
Public static function main (){
Self: run (new ConcreteFactory1 ());
Self: run (new ConcreteFactory2 ());
}
 
/**
* Call a factory instance to generate a product and output the product name
* @ Param $ factory AbstractFactory factory instance
*/
Public static function run (AbstractFactory $ factory ){
$ ProductA = $ factory-> createProductA ();
$ ProductB = $ factory-> createProductB ();
Echo $ productA-> getName (), '<br/> ';
Echo $ productB-> getName (), '<br/> ';
}
 
}
 
Client: main ();
?>

The difference between the factory method mode and the abstract factory Mode

Factory method mode:
An abstract product class can be derived from multiple specific product classes.
An abstract factory class can be derived from multiple factory classes.
Each factory class can only create one instance of a specific product class.

Abstract Factory mode:
Multiple abstract product classes. Each abstract product class can be derived from multiple specific product classes.
An abstract factory class can be derived from multiple factory classes.
You can create multiple product instances for each specific factory class.

Differences:
The factory method mode has only one abstract product class, while the abstract factory mode has multiple.
The factory method mode can only create one instance for a specific product type, while the abstract factory mode can create multiple instances.

Factory method mode and abstract factory Mode

Abstract Factory: it is a deeper layer than the factory model. This time, even the factory implementation classes are unknown. Different people can get different factory classes. So Abstract Factory classes are actually a factory class that can generate different factory classes.
To put it simply, if we regard the "generate object with factory" relationship as a level-1 generative relationship, the abstract factory method is the factory method with level-2 generative relationship. If the actual environment is more complex, it can be level 3 or even level 4, so you don't want to think too complicated, it's that simple.
The design model is well written, but please read it with inspiration. Don't go into it, because:
The design pattern was written earlier when the programmer's understanding of the program was still good at code compilation, so you will find that there are many features that seem so idiotic now, not to mention at all, we usually use this. This is because you are standing in the industrial age to see stone-age products, so you do not have to use certain models.
The design pattern is not specific to the java language, so you cannot use some features.
In actual work, the situation is far simpler than the situation mentioned in the design model. Some models are difficult for you to use.

The best way to read this book is to read it through quickly. It is not for you to skip reading or to read it patiently, but not to read it normally. After reading this article, you won't be so awesome, but after several years of development work, you will be able to look back and see a lot of things you don't understand, in the future development process, it will occasionally inspire you to write code.