Turn: Design Pattern-abstract factory pattern (concise and clear)

From: http://blog.csdn.net/ipqxiang/article/details/1955677

1. Abstract Factory Mode

Abstract Factory mode is the most abstract and general factory mode in all forms.

To facilitate the introduction of the abstract factory model, a new concept is introduced: product family ). A product family is a family of products with different product levels and functions.

 

The figure shows four product families distributed in three different product levels. You only need to specify the product family of a product and its hierarchical structure.

Introduce Abstract Factory Model

Abstract Factory refers to all objects in a product family that can be created by a factory level structure into different product levels. If you use a diagram to describe it, for example:

 

Ii. Structure of the abstract factory mode:

 

The product family is described as follows:

 

Abstract Factory role: this role is at the core of the factory method model and has nothing to do with the business logic of the application system.

Concrete Factory role: this role directly creates a product instance under the client call. This role contains the logic for selecting appropriate product objects, which is closely related to the business logic of the application system.

Abstract Product role: the class that assumes this role is the parent class of the object created in the factory method mode, or the interfaces they share.

Concrete Product role: Any product object created in the abstract factory model is an instance of a specific product category. This is what the client eventually needs, and it must be filled with the commercial logic of the application system.

3. program example:

This program demonstrates the abstract factory structure and does not have any practical value.

// Abstract factory pattern -- Structural example
Using system;

// "Abstractfactory"
Abstract class abstractfactory
{
// Methods
Abstract Public abstractproducta createproducta ();
Abstract Public abstractproductb createproductb ();
}

// "Concretefactory1"
Class concretefactory1: abstractfactory
{
// Methods
Override public abstractproducta createproducta ()
{
Return new producta1 ();
}
Override public synchronized actproductb createproductb ()
{
Return new productb1 ();
}
}

// "Concretefactory2"
Class concretefactory2: abstractfactory
{
// Methods
Override public abstractproducta createproducta ()
{
Return new producta2 ();
}

Override public synchronized actproductb createproductb ()
{
Return new productb2 ();
}
}

// "Abstractproducta"
Abstract class abstractproducta
{
}

// "Abstractproductb"
Abstract class abstractproductb
{
// Methods
Abstract Public void interact (abstractproducta );
}

// "Producta1"
Class producta1: abstractproducta
{
}

// "Productb1"
Class productb1: abstractproductb
{
// Methods
Override public void interact (abstractproducta)
{
Console. writeline (This + "interacts with" + );
}
}

// "Producta2"
Class producta2: abstractproducta
{
}

// "Productb2"
Class productb2: abstractproductb
{
// Methods
Override public void interact (abstractproducta)
{
Console. writeline (This + "interacts with" + );
}
}

// "Client"-the interaction environment of the products
Class Environment
{
// Fields
Private abstractproducta;
Private abstractproductb;

// Constructors
Public Environment (abstractfactory factory)
{
Abstractproductb = factory. createproductb ();
Abstractproducta = factory. createproducta ();
}
 
// Methods
Public void run ()
{
Abstractproductb. Interact (abstractproducta );
}
}

/// <Summary>
/// Clientapp test environment
/// </Summary>
Class clientapp
{
Public static void main (string [] ARGs)
{
Abstractfactory factory1 = new concretefactory1 ();
Environment e1 = new environment (factory1 );
E1.run ();

Abstractfactory factory2 = new concretefactory2 ();
Environment e2 = new environment (factory2 );
E2.run ();
}
}

 

4. Under what circumstances should I use the abstract factory model:

Abstract Factory models should be considered in the following situations:

• 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.
• This system has more than one product family, and the system only consumes one of them.
• Products belonging to the same product family are used together. This constraint must be reflected in the system design.
• The system provides a product library. All products use the same interface, so that the client does not rely on implementation.
  
  

V. Origin of Abstract Factory

It is said that the earliest application is used to create a system that can run in a Windows environment of different operating systems. For example, in windows and Unix systems, Windows Components are deployed. In each operating system, Windows components constitute a component family. We can use an abstract role to provide a function description, and the specific sub-classes provide specific implementations under different operating systems,

 

The product class diagram above has two product grade structures: button and text. There are two product families: Unix product family and Windows product family.

 

The system needs to create product objects according to the hierarchical structure of a factory. There are two specific factory roles, unixfactory and winfactory. The unixfactory object is used to create products in the Unix product family, while winfactory is used to create products in the Windows product family.

 

Obviously, a system can only run in a Windows environment of a certain operating system, rather than running on different operating systems at the same time. Therefore, the system can only consume products belonging to the same product family.

In modern applications, the scope of use of the abstract factory model has been greatly expanded, and the system is no longer required to consume only one product family.

Vi. Implementation of the abstract factory mode in the actual system

Herbivore
Carnivore: carnivals
Bison: ['baisn], an American or European buffalo

The following code demonstrates how to create an abstract factory for different animals in a computer game. Although animal species are different in different continents, the relationships between animals are retained.

// Abstract factory pattern -- real world example
Using system;

// "Abstractfactory"
Abstract class continentfactory
{
// Methods
Abstract Public herbivore createherbivore ();
Abstract Public carnivore createcarnivore ();
}

// "Concretefactory1"
Class africafactory: continentfactory
{
// Methods
Override public herbivore createherbivore ()
{Return New wildebeest ();}

Override public carnivore createcarnivore ()
{Return New lion ();}
}

// "Concretefactory2"
Class americafactory: continentfactory
{
// Methods
Override public herbivore createherbivore ()
{Return New BISON ();}

Override public carnivore createcarnivore ()
{Return new wolf ();}
}

// "Abstractproducta"
Abstract class herbivore
{
}

// "Abstractproductb"
Abstract class carnivore
{
// Methods
Abstract Public void eat (herbivore H );
}

// "Producta1"
Class wildebeest: herbivore
{
}

// "Productb1"
Class LION: carnivore
{
// Methods
Override public void eat (herbivore H)
{
// Eat wildebeest
Console. writeline (This + "Eats" + H );
}
}

// "Producta2"
Class bison: herbivore
{
}

// "Productb2"
Class Wolf: carnivore
{
// Methods
Override public void eat (herbivore H)
{
// Eat bison
Console. writeline (This + "Eats" + H );
}
}

// "Client"
Class animalworld
{
// Fields
Private herbivore;
Private carnivore;

// Constructors
Public animalworld (continentfactory factory)
{
Carnivore = factory. createcarnivore ();
Herbivore = factory. createherbivore ();
}

// Methods
Public void runfoodchain ()
{Carnivore. Eat (herbivore );}
}

/// <Summary>
/// Gameapp test class
/// </Summary>
Class gameapp
{
Public static void main (string [] ARGs)
{
// Create and run the Africa Animal World
Continentfactory Africa = new africafactory ();
Animalworld world = new animalworld (Africa );
World. runfoodchain ();

// Create and run the America Animal World
Continentfactory America = new americafactory ();
World = new animalworld (America );
World. runfoodchain ();
}
}

Another example of the abstract factory:

How to Design the abstract class factory.

VII. Principle of "openness-closeness"

The "open-closed" principle requires that the system be open to expansion and closed to modification. To enhance its functions through expansion. For systems involving multiple product families and multiple product level structures, the function enhancements include:

Added product family: Abstract Factory supports the "open-closed" principle.

Add the hierarchical structure of New Products: All factory roles need to be modified, and the "open-closed" principle is not well supported.

In combination, the abstract factory model supports the addition of new products in a skewed manner, which facilitates the addition of new product families, however, it is not convenient to add a new product level structure.

 

 

References:
Min Hong, Java and mode, e-Industry Press
[Us] James W. Cooper, C # design model, Electronic Industry Press
[Us] Alan shalloway James R. Trott, design patterns explained, China Power Press
[Us] Robert C. Martin, Agile Software Development-principles, models and practices, Tsinghua University Press
[Us] Don box, Chris sells, 1st. Net essence: Public Language Runtime Library, China Power Press

Turn: Design Pattern-abstract factory pattern (concise and clear)