First, let's consider a user interface toolkit that supports the look and feel standard, such as Motif and Presentation Manager. In order to ensure the consistency of look and feel, an application should not hard code its window components for a specific look and feel. Because this will make it difficult to change the appearance of the window in the future.

To solve this problem, we define a WidgetFactory class. This class has methods for creating different Window components. For example, the createcrossbar method will be used to create a ScrollBar, and the createWindow method will create a Window class. Each type of Window component that can be created by the WidgetFactory method corresponds to an abstract class. Such as Window and ScrollBar here. WidgetFactory is an abstract class whose subclasses will be used to create concrete Window components. As shown in the figure below:

 

 

 

As can be seen from the above, when we need to create another kind of look and feel, we only need to inherit the WidgetFactory abstract factory class and override its methods.

 

The Abstract Factory pattern is used here. The structure diagram of this mode is as follows:

 

 

 

 

Abstract Factory mode has the following characteristics:

1. The customer is separated from the specific implementation. Customers use abstract products. Separation of implementation and use.

2. Easy to expand new product categories. A new product category can be easily obtained by implementing a new entity factory and inheriting from the abstract factory.

3. Good product consistency. An application can only use objects in the same series at a time. For example, MotifWindow and PMScrollBar cannot be used together.

4. Abstract Factory also has a problem. That is, it is not easy to expand new types of products. To solve this problem, there will be a solution later.

 

Let's look at an example of an abstract factory class. The program is written in Java.

 

The first is the abstract factory class

AbstractFactory.java:

public abstract class AbstractFactory {
Button button;
TextBox textbox;
public abstract void createButton();
public abstract void createTextbox();
}

　　

As you can see, this class is used to generate product buttons and textboxes. Button and TextBox are also abstract classes.

Button.java:

public abstract class Button {
protected abstract void createShape();
}
TextBox.java:

public abstract class TextBox {
protected abstract void createText();
}

　　

LinuxFactory and WindowsFactory inherit from AbstractFactory. Their createButton generates Linux button, Linux textbox, windows button and windows textbox respectively.

LinuxFactory.java:

public class LinuxFactory extends AbstractFactory {
public void createButton() {
button = new LinuxButton();
button.createShape();
}

public void createTextbox() {
textbox = new LinuxTextBox();
textbox.createText();
}
}
WindowsFactory.java:

public class WindowsFactory extends AbstractFactory {
public void createButton() {
button = new WindowsButton();
button.createShape();
}

public void createTextbox() {
textbox = new WindowsTextBox();
textbox.createText();
}
}
LinuxButton.java:

public class LinuxButton extends Button {
protected void createShape() {
System.out.println("create Linux Button");
}
}
LinuxTextBox.java:

public class LinuxTextBox extends TextBox {
protected void createText() {
System.out.println("create linux textbox");
}
}
WindowsButton.java:

public class WindowsButton extends Button {
protected void createShape() {
System.out.println("create windows button");
}
}
WindowsTextBox.java:

public class WindowsTextBox extends TextBox {
protected void createText() {
System.out.println("create windows textbox");
}
}

　　

 

The following Client class shows the use of objects in the abstract factory pattern:

Client.java:

public class Client {
public static void main(String args[]) {
AbstractFactory factory = new LinuxFactory();
factory.createButton();
factory.createTextbox();
factory = new WindowsFactory();
factory.createButton();
factory.createTextbox();
}
}

　　

As can be seen from the Client class, when using the abstract factory pattern, create a factory class with an entity factory, and then create parts through the abstract factory class. The physical products created are transparent to customers.

Let's look at this design again. We can create buttons and textboxes through AbstractFactory, but now we need to create another product TextField. This is more difficult. We need to change Abstract Factory and change all classes that inherit AbstractFactory. Obviously, this is very inappropriate. Therefore, the Abstract Factory pattern has some problems when extending new products.

One solution is to provide a parameter to the operation of creating an object, which is used to specify the type of object to be created. Although this is an available solution, there are some problems.

Therefore, we need to know that extending new products is not the strength of the Abstract Factory model.