Design Pattern Learning Factory mode [go]

Factory mode Notes

Excerpted from http://blog.csdn.net/wuzhekai1985

Design patterns in the field of software provide developers with an effective way to use expert design experience. The design pattern uses the important characteristic of object-oriented programming language: encapsulation, inheritance, polymorphism, really comprehend the essence of design pattern is probably a long process, need to accumulate a lot of practical experience. Recently read the design pattern of the book, for each model, with C + + write a small example, deepen understanding. The main reference is "Big talk design mode" and "design pattern: The basis of reusable object-oriented software" two books. This article describes the implementation of the factory pattern.

The factory model belongs to the creation model, which can be divided into three types, simple Factory mode, factory method mode and abstract Factory mode. That sounds almost like a factory model. The following introduction, the first introduction of the Simple factory model, its main feature is the need to make judgments in the factory class, so as to create the corresponding products. When adding new products, you need to modify the factory class. A little abstract, for example, I understand. There is a manufacturer of processor cores, which has only one factory, capable of producing two types of processor cores. What kind of processor core the customer needs, be sure to show to the production plant. The following is an implementation scenario.

1 enumCTYPE {corea, Coreb}; 2 classSinglecore3 {    4  Public:    5     Virtual voidShow () =0; 6 }; 7 //Single Core A8 classSinglecorea: PublicSinglecore9 {    Ten  Public:     One     voidShow () {cout<<"Singlecore A"<<Endl;}  A };  - //Single Core B - classSinglecoreb: PublicSinglecore the {     -  Public:     -     voidShow () {cout<<"Singlecore B"<<Endl;}  - };  + //the only factory that can produce two types of processor cores, in-house judgment - classFactory + {     A  Public:      atsinglecore* Createsinglecore (enumCTYPE CTYPE) -     {     -         if(CType = = Corea)//Factory internal judgment -             return NewSinglecorea ();//production of nuclear a -         Else if(CType = =Coreb) -             return NewSinglecoreb ();//production of nuclear b in         Else     -             returnNULL;  to     }     +};

The main drawbacks of this design have been mentioned before, that is, to add new kernel types, you need to modify the factory class. This violates the open closure principle: Software entities (classes, modules, functions) can be extended, but cannot be modified. So, the factory method pattern appeared. The so-called factory method pattern refers to defining an interface for creating objects, so that subclasses decide which class to instantiate. The Factory method defers the instantiation of a class to its subclasses.

It sounds abstract, or it is explained in the example just now. The producer of the processor's core made a lot of money and decided to set up another factory dedicated to the B-type single-core, and the original factory was designed to produce a single core of type A. At this point, the customer to do is to find a good factory, such as to a model of the nuclear, to find a factory to, or to find the B factory, no longer need to tell the factory specifically what type of processor core. Here is an implementation scenario.

1 classSinglecore2 {    3  Public:    4     Virtual voidShow () =0; 5 }; 6 //Single Core A7 classSinglecorea: PublicSinglecore8 {    9  Public:    Ten     voidShow () {cout<<"Singlecore A"<<Endl;}  One };  A //Single Core B - classSinglecoreb: PublicSinglecore - {     the  Public:     -     voidShow () {cout<<"Singlecore B"<<Endl;}  - };  - classFactory + {     -  Public:     +     Virtualsinglecore* Createsinglecore () =0;  A };  at //production of a nuclear plant - classFactorya: PublicFactory - {     -  Public:     -singlecorea* Createsinglecore () {return NewSinglecorea;}  - };  in //Plant producing B-core - classFactoryb: PublicFactory to {     +  Public:     -singlecoreb* Createsinglecore () {return NewSinglecoreb;}  the};

Factory method models also have drawbacks, and each additional product requires an additional plant for the object. If the company develops rapidly and launches many new processor cores, it will have to open a new plant. In the C + + implementation, it is to define a factory class. Obviously, the factory method pattern requires more class definitions than the simple factory model.

Given the simple factory model and the factory approach model, why should there be an abstract factory model? How does it work? To cite this example, the company's technology continues to evolve, not only to produce single-core processors, but also to produce multicore processors. Both the simple Factory mode and the factory method mode are now beyond. The abstract factory model has appeared. It is defined to provide an interface that creates a series of related or interdependent objects without specifying their specific classes. In this application, the company also opened two factories, one dedicated to the production of a single core multi-core processor, and another factory dedicated to the production of B-type single-core multicore processors, the implementation of the code below.

1 //Single Core2 classSinglecore3 {    4  Public:    5     Virtual voidShow () =0; 6 }; 7 classSinglecorea: PublicSinglecore8 {    9  Public:    Ten     voidShow () {cout<<"Single Core A"<<Endl;}  One };  A classSinglecoreb: PublicSinglecore - {     -  Public:     the     voidShow () {cout<<"Single Core B"<<Endl;}  - };  - //Multi-Core - classmulticore + {     -  Public:     +     Virtual voidShow () =0;  A };  at classMulticorea: Publicmulticore - {     -  Public:     -     voidShow () {cout<<"Multi Core A"<<Endl;}  -      - };  in classMulticoreb: Publicmulticore - {     to  Public:     +     voidShow () {cout<<"Multi Core B"<<Endl;}  - };  the //Factory * classcorefactory $ {    Panax Notoginseng  Public:     -     Virtualsinglecore* Createsinglecore () =0;  the     Virtualmulticore* Createmulticore () =0;  + };  A //Factory A, designed to produce a type a processor the classFactorya: Publiccorefactory + {     -  Public:     $singlecore* Createsinglecore () {return NewSinglecorea ();}  $multicore* Createmulticore () {return NewMulticorea ();}  - };  - //Factory B, dedicated to the production of B-type processors the classFactoryb: Publiccorefactory - {    Wuyi  Public:     thesinglecore* Createsinglecore () {return NewSinglecoreb ();}  -multicore* Createmulticore () {return NewMulticoreb ();}  Wu};

At this point, the factory model is finished. Use rational Rose 2003 software to give a UML diagram of three factory models to deepen impressions.

UML diagram for simple Factory mode:

UML diagram of the factory method:

UML diagram for abstract Factory mode:

Personal PS:

Simple Factory mode: A factory class, the factory produces what needs to tell the factory class;

Factory method Mode: Each factory produces a commodity, need what goods, only need to find the corresponding factory can be;

Abstract Factory mode: An abstract factory class, an abstract commodity class, which defines the interface between the production and the specific commodity, which is determined by the sub-category of the particular factory.

Design Pattern Learning Factory mode [go]