学习设计模式-----策略模式

以下绝大部分内容转自大话设计模式（C++）

定义算法家族，分别封装起来，让它们之间可以互相替换，让算法变化，不会影响到用户 
GOOD:适合类中的成员以方法为主，算法经常变动；简化了单元测试（因为每个算法都有自己的类，可以通过自己的接口单独测试。 策略模式和简单工厂基本相同，但简单工模式只能解决对象创建问题，对于经常 变动的算法应使用策略模式。 
BUG:客户端要做出判断

（一）策略与工厂的结合

class COperation

{

public:

    int first;

    int second;

    virtual double getresult()

    {

        double result=0;

        return result;

    }

};

class AddOperation:class COperation

{

public:

    AddOperation(int a,int b)

    {

        first=a;

        second=b;

    }

    virtual double getresult()

    {

        result=first+second;

        return result;

    }

};

class Context

{

private:

    COperation *op;

public:

    Context(char cType)

    {

        switch(cType)

        {

        case'+':

            op=new AddOperation(a,b);

            break;

        default:

            op=new AddOperation();

            break;    

        }

    }

    double getresult()

    {

        return op->getresult();

    }

};

int main()

{

    int a,b;

    cin>>a>>b;

    Context oper=new Context('+');

    cout<<oper->getresult()<<endl;

    return 0;   

}

 

单一职责原则

就一个类而言，应该仅有一个引起它变化的原因。 如果一个类承担的职责过多，就等于把这些职责耦合在一起，  一个职责的变化可能会削 弱或者抑制这个类完成其它职力这种耦合会导制脆弱的设计，当变化发生时，设计会 遭受到意想不到的破坏。 如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。

开放――封闭原则

软件实体可以扩展，但是不可修改。即对于扩展是开放的，对于修改是封闭的。面对需求，对程序的改动是通过增加代码来完成的，而不是改动现有的代码。 当变化发生时，我们就创建抽象来隔离以后发生同类的变化。

里氏代换原则
一个软件实体如果使用的是一个父类的话，那么一定适用其子类。而且它察觉不出父类对象和子类对象的区别。也就是说：在软件里面，把父类替换成子类，程序的行为没有
变化。

依赖倒转原则
抽象不应该依赖细节，细节应该依赖抽象。即针对接口编程，不要对实现编程。高层模块不能依赖低层模块，两者都应依赖抽象。