Lecture 3rd: Abstract Factory Model

2005.11.15 Li Jianzhong

New Problems

Common Object creation methods:

 

New problem:

-Implementation dependency, cannot cope with "Specific instantiation type" Changes

Solution:

-Encapsulation change point-where and where

-Hidden Lines: If there is no change, no additional encapsulation is required!

 

The origin of the factory Model

The change point is "Object creation", so the "Object creation" is encapsulated"

Interface-oriented programming-dependent interface rather than dependency implementation

The simplest solution:

 

Create a series of mutually dependent objects

Assume a game development scenario:

We need to construct "roads", "Houses", "tunnels", and "Jungle "...... And so on

 

Simple factory Problems

Simple factory problems:

-Cannot cope with changes to "different series objects. For example, there are game scenarios of different styles-corresponding to different styles of roads, houses, tunnels ...... The customer program is relatively stable, but the static simple factory may become a change point.

Solution:

-Use object-oriented technology to "encapsulate" Changes

 

Motivation)

In software systems,A series of interdependent objects". At the same time, due to changes in requirements,More series objects are often created.Work.

How to deal with this change? How can we bypass the conventional object creation method (new) and provide an "encapsulation mechanism" to avoid the tight coupling between the customer program and the "Multi-series object creation work?

 

Intent)

Provides an interface for this interface to create a series of "related or interdependent objects" without specifying their specific classes.

-- Design Pattern GoF

 

Structure)

A1 and B1 are a series, while A2 and B2 are another series. ConcreteFactory1 is the factory method for creating Series 1, and ConcreteFactory2 is the factory method for creating Series 2. The Client of the Client only depends on AbstractFactory, AbstractProductA, and AbstractProductB. That is, the Client program does not depend on the specific implementation, but only on the abstract class.

If we need to create a Series 3 to apply it to the customer program, we only need to write another series 3 factory that inherits from AbstractFactory, which provides two implementations:

CreateProductA ();

CreateProductB ();

They return ProductA3 (inherited from AbstractProductA) and ProductB3 (inherited from AbstractProductB ).

That is to say, if Series 3 is added, the Client program does not need to be changed at all. You may only need to add some new dll files to cope with the changes.

 

AbstractFactory application in game framework

In this example, Road is AbstractProductA1, Building is AbstractProductB1, and FacilitiesFactory is AbstractFactory.

 

Customer Program

It can be seen that the client program depends on all abstract classes, and no specific implementation classes have been found in the client program code. This is because the abstract class does not need to be changed when the series needs to be changed, but the implementation of an abstract class is added. Because the client program only depends on the abstract, therefore, the customer program does not need to be changed when the series changes.

Implementation of a modern style series

Implementation of specific modern style series factories

Application to specific programs (modern style)

Application to specific programs (classic style)

As we can see, when the style is changed from Modern to Classic, the encapsulated GameManager client program has not changed. This is what we want. The logic of GameManager is very complex. Now it is stable and can greatly facilitate our work.

 

Key points of the AbstractFactory Mode

1. If there is no need to cope with changes to the "Multi-series object creation", there is no need to use the AbstractFactory mode. In this case, a simple static factory is enough.

2. "series objects" refer to the relationships between these objects, such as the dependencies between "roads" and "Houses" in game development scenarios, "road" and "authentic" dependencies.

3. The AbstractFactory mode is mainly used to cope with changes in the demand of the "new series. The disadvantage is that it is difficult to cope with the changes in the demand for "new objects.

4. In the AbstractFactory mode, FactoryMethod is often used together to cope with changes in the "Object creation" requirement.

For example, if the style does not change frequently, but other content changes (for example, the class to add a road today and the class to add a desert tomorrow ), in this way, the abstract factory model will make the system very bad. Because the subclass in the abstract factory class has changed, all classes that implement the abstract factory need to be changed and implemented again, re-compile and deploy.

That is to say, the key depends on the change direction and axis. If the axis of change is in multiple styles, the abstract factory mode is very suitable; If the axis of change is in the abstract factory, it is best not to use this mode.

 

AbstractFactory application in. NET Framework

In ASP. when compiling. Net, first compile the aspx Page file into a class, and then compile CodeBehind into a class. The CodeBehind class inherits from the Page class, the aspx page class inherits from the CodeBehind class. The WebControl and HtmlControl processed on the aspx page actually use AbstractFactory, but this application is more reflected in the business layer.

 

Difference between Builder mode and AbstractFactory Mode

The Builder mode emphasizes the strict process of constructing the object part. It constructs all parts of the entire object. After the building is stabilized, the parts are changing and finally combined into a whole object.

The AbstractFactory mode builds a set of interactive objects.

Objects that depend on each other and interact with each other are different from each other of an object.

2010.9.22