c ++ design pattern - factory method pattern

"Object Create" mode
bypassed by new "object creation" mode, to avoid the tight coupling object creation (new) process resulting (dependent concrete class), to support a stable object created. It is the first step after the interface abstraction.
Motivation
in software systems, often faced with the creation of objects work; due to changes in demand, the need to create specific types of objects often change.

How to respond to this change? How to create a method (new) bypassing the conventional object to provide a "package mechanism" to avoid tightly coupled client and this "specific object creation work"?
Schema definitions
define an interface for creating an object, but let subclasses decide which class to instantiate technology. Factory Method retarder such that a class instance (object: decoupling means: virtual function) to subclasses.
- "Design Patterns" GoF
structure
QQ picture 20200119233514.png
example
Suppose we design a file splitter

class ISplitter{//Product抽象类
public:
    virtual void split()=0;
    virtual ~ISplitter(){}
};
//以下具体的Product类
class BinarySplitter : public ISplitter{
    
};

class TxtSplitter: public ISplitter{
    
};

class PictureSplitter: public ISplitter{
    
};

class VideoSplitter: public ISplitter{
    
};
class MainForm : public Form
{
    TextBox* txtFilePath;
    TextBox* txtFileNumber;
    ProgressBar* progressBar;

public:
    void Button1_Click(){


        
        ISplitter * splitter=
            new BinarySplitter();//依赖具体类
        
        splitter->split();

    }
};

In mainform above which a new concrete class, which is a compile-time dependent, there is the need to compile BinarySplitter by
using an object-oriented approach we make the following improvements

//工厂基类
class SplitterFactory{
public:
    virtual ISplitter* CreateSplitter()=0;
    virtual ~SplitterFactory(){}
};
//具体工厂
class BinarySplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new BinarySplitter();
    }
};

class TxtSplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new TxtSplitter();
    }
};

class PictureSplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new PictureSplitter();
    }
};

class VideoSplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new VideoSplitter();
    }
};

class MainForm : public Form
{
    SplitterFactory*  factory;//工厂

public:
    
    MainForm(SplitterFactory*  factory){
        this->factory=factory;
    }
    
    void Button1_Click(){

        
        ISplitter * splitter=
            factory->CreateSplitter(); //多态new
        
        splitter->split();

    }
};

Thus, only rely MainForm ISplitter SplitterFactory and two abstract classes, rather than rely on specific classes
summarized
1.Factory Method for mode coupling between the user and the specific type of isolation class object. The face of a specific type of constantly changing, tightly coupled (new) will lead to fragile software.
2.Factory Method pattern through object-oriented approach, the specific work to be an object to create a subclass of delay, in order to achieve the policy an extension (but not change), and a better solution to this tightly coupled relationship.
3.Factory Method mode to solve the "single object" needs changes. Disadvantage that they require creation method / the same parameters.

Guess you like

Origin www.cnblogs.com/Redwarx008/p/12216080.html