简单工厂模式

工厂模式

客户类和工厂类分开
消费者任何时候需要某种产品，只需向工厂请求即可。
消费者无须修改就可以接纳新产品，缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供

第一，基类存放数据

第二，派生类有很多，派生类存放数据的操作

第三，实现接口类，用静态函数实现调用各种派生类

class Operation    //基类存放数据
{
public:
    double numberA, numberB;//两个数
    virtual double  getResult()//获取结果
    {
        return 0;
    }
};

class addOperation :public Operation//派生类存放操作
{
    double getResult()
    {
        return numberA + numberB;
    }
};


class subOperation :public Operation
{
    double getResult()
    {
        return numberA - numberB;
    }
};

class mulOperation :public Operation
{
    double getResult()
    {
        return numberA*numberB;
    }
};

class divOperation :public Operation
{
    double getResult()
    {
        return numberA / numberB;
    }
};

class operFactory //实现调用改革吃哦啊做
{
public:
    static Operation *createOperation(char c)
    {
        switch (c)
        {
        case '+':
            return new addOperation;
            break;

        case '-':
            return new subOperation;
            break;

        case '*':
            return new mulOperation;
            break;

        case '/':
            return new divOperation;
            break;
        }
    }
};

int mainV()
{
    Operation *oper = operFactory::createOperation('-');
    oper->numberA = 9;
    oper->numberB = 99;
    cout << oper->getResult() << endl;

    cin.get();
    return 0;
}

优点

外界可以从直接创建具体产品对象的尴尬局面摆脱出来，仅仅需要负责“消费”对象就可以。而不必管这些对象究竟如何创建及如何组织，明确了各自的职责和权利，有利于整个软件体系结构的优化

缺点

由于工厂类集中了所有实例的创建逻辑，违反了高内聚分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则需要改变工厂类。
当系统中的具体产品类不断增多的时候，可能会出现要求工厂类根据不同条件创建不同实例的需求，这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利

使用场景

工厂类负责创建的对象比较少；
客户只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心