简单工厂模式-C++

前言：使用C++实现了一个简单工厂模式，并对除零操作做了异常处理。
设计原则：设计模式体现了代码的耦合性， 内聚性以及可维护性，可扩展性，重用性，灵活性。

• 代码重用性（即：相同功能的代码，不用多次编写）
• 可读性（即：编程规范性，便于其他程序员的阅读和理解）
• 可扩展性（即：当需要增加新的功能时，非常的方便，称为可维护）
• 可靠性（即：当我们增加新的功能后，对原来的功能没有影响）
• 使程序呈现高内聚，低耦合的特性

I 单一职责原则（Single responsibility）

1、降低类的复杂度，一个类只负责一项职责；
2、提高类的可读性，可维护性；
3、降低变更引起的风险;
4、通常情况下，应当遵守单一职责原则， 只有逻辑足够简单，才可以在方法级违反单一职责原则。

II 接口隔离原则（Interface Segregation）

1、类A通过接口 Interface1、2 依赖类B，类C通过接口 Interface1、3 依赖类D，如果接口 Interface 对于 类A 和 类C 来说不是最小接口，那么 类B 和 类D 必须去实现他们不需要的方法。
2、将接口 Interface 拆分为独立的几个接口，类A 和 类C 分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

III 依赖倒转原则（Dependence Inversion）

1、高层模块不应该依赖低层模块，二者都应该依赖其抽象（缓冲层）；
2、抽象不应该依赖细节，细节应该依赖抽象；
3、依赖倒转(倒置)的中心思想是面向接口编程;
4、依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中， 抽象指的是接口或抽象类，细节就是具体的实现类；
5、使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

IV 里氏替换原则（Liskov Substitution）

1、里氏替换原则(Liskov Substitution Principle)在1988年，由麻省理工学院一位姓里的女士提出；
2、如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象；
3、在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法；
4、继承实际上让两个类耦合性增强了，给程序带来侵入性。在适当的情况下，可以通过聚合，组合，依赖来解决问题；
5、继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。

V 开闭原则 OCP（Open Closed）

1、开闭原则(Open Closed Principle) 是编程中最基础、最重要的设计原则；
2、一个软件实体，比如类，模块和函数应该对提供方扩展开放，对使用方修改关闭。用抽象构建框架，用实现扩展细节；
3、当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化；
4、编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。

VI 迪米特法则（Demeter）

1、一个对象应该对其他对象保持最少的了解（最少知道原则 LKP）。
2、类与类关系越密切，耦合度越大。要求降低类之间耦合，而不是完全解耦。
3、迪米特法则(Demeter Principle)，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供public方法，不对外泄露任何信息。
4、迪米特法则更简单的定义：只与直接的朋友通信。
5、直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合 等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。

VII 合成复用原则（Composite Reuse）

合成复用原则 尽量使用组合/聚合的方式，而不是使用继承。

1、找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
2、针对接口编程，而不是针对实现编程。
3、为了交互对象之间的松耦合设计而努力。

设计模式分类：创建型（Creational），行为性（Creational），结构型（Creational）。

简单工厂模式-创建型

#include <iostream>

using namespace std;

enum Op{
    PLUS, SUB, MUL, DIV
};

#define XX(op) op

class bad_div : public exception{
public:
    const char* what() const noexcept { return "bad divide!"; }
};

//运算符接口
class Operator {
public:
    Operator() = default;
    Operator(double first, double second)
        : m_first(first), m_second(second) {
    }
    void setVal(double first, double second) {
        m_first = first;
        m_second = second;
    }
    virtual double getResult() = 0;
protected:
    double m_first;
    double m_second;
};

class Plus : public Operator {
public:
    Plus() = default;
    Plus(double first, double second)
        :Operator(first, second) {}
    double getResult() {
        return m_first + m_second;
    }
};

class Subtract : public Operator {
public:
    Subtract() = default;
    Subtract(double first, double second)
        :Operator(first, second) {}
    double getResult() {
        return m_first - m_second;
    }
};

class Multiply : public Operator {
public:
    Multiply() = default;
    Multiply(double first, double second)
        :Operator(first, second) {}
    double getResult() {
        return m_first * m_second;
    }
};

class Divide : public Operator {
public:
    Divide() = default;
    Divide(double first, double second)
        :Operator(first, second) {}
    double getResult() {
        try {
            if (m_second == 0)
                throw bad_div();
            return m_first / m_second;
        } catch (exception& ex) {
            cout << ex.what() << endl;
            exit(1);
        }
        
    }
};

class OperatorFactory {
public:
    Operator* getObject(Op op) {
        switch (op)
        {
        case PLUS:
            return new Plus;
        case SUB:
            return new Subtract;
        case MUL:
            return new Multiply;
        case DIV: {
            return new Divide;
        }
            return new Divide;

        default:
            return nullptr;
            break;
        }
    }
};


//运算符工厂

int main() {
    OperatorFactory fac;
    Operator* opera = nullptr;
    opera = fac.getObject(PLUS);
    if (!opera) {
        cout << "get Operator object fail." << endl;
        exit(1);
    }
    opera->setVal(1, 2);
    cout << opera->getResult() << endl;

    opera = fac.getObject(SUB);
    if (!opera) {
        cout << "get Operator object fail." << endl;
        exit(1);
    }
    opera->setVal(1, 2);
    cout << opera->getResult() << endl;

    opera = fac.getObject(MUL);
    if (!opera) {
        cout << "get Operator object fail." << endl;
        exit(1);
    }
    opera->setVal(1, 2);
    cout << opera->getResult() << endl;

    opera = fac.getObject(DIV);
    if (!opera) {
        cout << "get Operator object fail." << endl;
        exit(1);
    }
    opera->setVal(1, 2);
    cout << opera->getResult() << endl;

    opera = fac.getObject(DIV);
    if (!opera) {
        cout << "get Operator object fail." << endl;
        exit(1);
    }
    opera->setVal(1, 0);
    cout << opera->getResult() << endl;


    return 0;
}

优点

工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅“消费”产品；简单工厂模式通过这种做法实现了对责任的分割，它提供了专门的工厂类用于创建对象。
客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于一些复杂的类名，通过简单工厂模式可以减少使用者的记忆量。
通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。

缺点

由于工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。
使用简单工厂模式将会增加系统中类的个数，在一定程序上增加了系统的复杂度和理解难度。
系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。
简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

使用场景

工厂类负责创建的对象比较少：由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。
客户端只知道传入工厂类的参数，对于如何创建对象不关心：客户端既不需要关心创建细节，甚至连类名都不需要记住，只需要知道类型所对应的参数。