C + + design mode----Factory mode

The following two types of problems are often encountered in object-oriented system design:

1) In order to improve cohesion and loose coupling, we often abstract some classes of public interfaces to form abstract base classes or interfaces. This allows us to point to the actual subclass implementation by declaring a pointer to the base class to achieve the polymorphic purpose. One problem that is easy to come up with is that n-ary subclasses inherit from the abstract base class, and we have to write code like newxxx every time we want to use subclasses. This brings two questions.

① The client programmer must know the name of the actual subclass (when the system is complex, naming will be a very bad problem, in order to handle possible name collisions, some names may not be good readability and memory,

Programmer's strange personal preference)
The extensibility and maintenance of ② programs is becoming more and more difficult.

2) There is also a case where the parent class does not know exactly which specific subclass to instantiate.

The above two questions also lead to the two most important features of the factory model:
1) Define an interface for creating objects, encapsulating the creation of objects;
2) The work of the materialized class is deferred to the subclass.

UML Class Diagram

　　

, Factorya is responsible for the production of Producta,factoryb concentrate on the production of Productb,factorya and Factoryb no relationship between, if the later, if the need to produce PRODUCTC, We can create a FACTORYC factory class, which is dedicated to the production of PRODUCTC class products. Since there is no relationship between Factorya, Factoryb, and Factoryc, when joining FACTORYC, there is no effect on the work of Factorya and Factoryb, and when testing the code, Only unit tests for FACTORYC and PRODUCTC are required, and Factorya and Factoryb do not have to be tested, eliminating a lot of uninteresting and tasteless testing.

Applicable occasions

The meaning of the factory method pattern is to define a factory interface that creates the product objects, deferring the actual creation to subclasses. The Core factory class is no longer responsible for product creation, so that the core class becomes an abstract factory role and is responsible only for the interfaces that a specific factory subclass must implement, and the benefit of further abstraction is that the factory method pattern allows the system to introduce new products without modifying the specific factory roles.

1. At the beginning of the design, considering that the product will be extended in the later stage, the factory method model can be used;
2. If the product structure is more complex, the factory method model can be used.

Since the use of design patterns is a detailed design, it is necessary to make a decision, so there is a need to weigh a number of factors, rather than using design patterns in order to use design patterns.

#include <iostream>using namespacestd;classproduct{ Public:    Virtual voidShow () =0;};classProductA: Publicproduct{ Public:    voidShow () {cout<<"I ' m producta"<<Endl; }};classPRODUCTB: Publicproduct{ Public:    voidShow () {cout<<"I ' m PRODUCTB"<<Endl; }};classfactory{ Public:    VirtualProduct *createproduct () =0;};classFactorya: Publicfactory{ Public: Product*createproduct () {return Newproducta (); }};classFactoryb: Publicfactory{ Public: Product*createproduct () {return NewPRODUCTB (); }};intMainintARGC,Char*argv []) {Factory*factorya =NewFactorya (); Product*producta = factorya->createproduct (); ProductA-Show (); Factory*factoryb =NewFactoryb (); Product*PRODUCTB = factoryb->createproduct (); PRODUCTB-Show (); if(Factorya! =NULL) {        DeleteFactorya; Factorya=NULL; }    if(ProductA! =NULL) {        Deleteproducta; ProductA=NULL; }    if(Factoryb! =NULL) {        DeleteFactoryb; Factoryb=NULL; }    if(PRODUCTB! =NULL) {        DeletePRODUCTB; PRODUCTB=NULL; }    return 0;}

Reference: C + + Design mode-factory method mode

C + + design mode----Factory mode