李建忠设计模式之“单一职责”模式

在软件组件的设计中，如果责任划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。

典型模式：Decorator、Bridge

装饰器模式（Decorator）

定义

动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类（继承）更为灵活（消除重复代码 & 减少子类个数）。

——《设计模式》GoF

动机

• 在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引人的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合(扩展功能的组合）会导致更多子类的膨胀。
• 如何使“对象功能的扩展"能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？ 从而使得任何“功能扩展变化"所导致的影响将为最低？

结构图

代码

// 流基类
class Stream{
public:
    virtual char Read(int number) = 0;
    virtual void Seek(int position) = 0;
    virtual void Write(char data) = 0;
    virtual ~Stream();
};

// 文件流类
class FileStream : public Stream{
public:
    virtual char Read(int number){
        //读文件流
    }
    virtual void Seek(int position){
        //定位文件流
    }
    virtual void Write(char data){
        //写文件流
    }
};
// 文件流类
class MemeryStream : public Stream{
public:
    virtual char Read(int number){
        //读内存流
    }
    virtual void Seek(int position){
        //定位内存流
    }
    virtual void Write(char data){
        //写内存流
    }
};
//扩展操作基类
class DecoratorStream : public Stream{
protected:
    Stream *stream; //...
    DecoratorStream(Stream stm): stream(stm){}
}

// 扩展操作:加密
class CrypToStream : public DecoratorStream{
public:
    CrypToStream(Stream stm):DecoratorStream(stm){}

    virtual char Read(int number){
        //额外的加密操作...
        stream->Read(number); //读文件流
        //额外的加密操作...
    }
    virtual void Seek(int position){
        // 额外的加密操作...
        stream::Seek(position); //定位文件流
        //额外的加密操作...
    }
    virtual void Write(byte data){
        //额外的加密操作...
        stream::Write(data); //写文件流
        // 额外的加密操作...
    }
};
// 扩展操作：缓存
class BufferedStream : public DecoratorStream{
public:
    BufferedStream(Stream stm):DecoratorStream(stm){} 
    //...
}

void Process(){
    FileStream fs = new FileStream(); //文件流
    CrypToStream* cfs = new CrypToStream(fs); //加密文件流
    BufferedStream bfs = new BufferedStream(fs); //缓存文件流
    BufferedStream bcfs = new BufferedStream(cfs); //缓存加密文件流

}

对于上述例子来说，普通继承方式和装饰器模式的类图关系如下图所示，可以发现装饰器模式极大的简化了类的数量，使得类的层次结构变得更加简洁。如果一个类拥有n个子类和m个操作，那么采用通继承方式将会有1+n+n*m!/2个类，但是对于装饰器模式来说，只有1+n+1+m个类。

要点

• 通过采用组合而非继承的手法，Decorator模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了使用继承带来的“灵活性差”和“多子类衍生问题”。
• Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类。
• Decorator模式的目的并非解决“多子类衍生的多继承”问题，Decorator模式应用的要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。

总结

装饰器模式将扩展功能封装，采用组合而非继承的手法使得客户程序根据需求动态的扩展多个功能，而不是由提供类的开发人员将所有组合方式悉数枚举。

桥方法模式（Bridge）

定义

将抽象部分(业务功能)与实现部分(平台实现)分离，使它们都可以独立地变化。

——《设计模式》GoF

动机

• 由于某些类型的固有的实现逻辑，使得它们具有两个变化的维度，乃至多个纬度的变化。
• 如何应对这种“多维度的变化”? 如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化，而不引入额外的复杂度?

结构图

代码

class Messager{
protected:
    MessagerImpl* messagerImpl; // 实现类获取
public:
    Messager(MessagerImpl* msgImpl):messagerImpl(msgImpl){}

    virtual void Login(string username, string password) = 0;
    virtual void SendMessage(stringmessage) = 0;
    virtual void SendPicture(Image image) = 0;
    virtual ~Messager() {}
};
class MessagerImpl{
public:
    virtual void PlaySound() = 0;
    virtual void DrawShape() = 0;
    virtual void WriteText() = 0;
    virtual void Connect() = 0;
    virtual ~MessagerImpl() {}
}

//平台实现
class PCMessagerImpl : public MessagerImpl{
public:
    virtual void PlaySound(){
        // **********
    }
    virtual void DrawShape(){
        // **********
    }
    virtual void WriteText(){
        // **********
    }
    virtual void Connect(){
        // **********
    }
};
class MobileMessagerImpl : public MessagerImpl{
public:
    virtual void PlaySound(){
        // ==========
    }
    virtual void DrawShape(){
        // ==========
    }
    virtual void WriteText(){
        // ==========
    }
    virtual void Connect(){
        // ==========
    }
};

// 业务抽象
class MessagerLite : public Messager{
public:
    MessagerLite(MessagerImpl msgImpl):Messager(msgImpl){}

    virtual void Login(string username, string password){
        messagerImpl->Connect();
        // ........
    }
    virtual void SendMessage(string message){
        messagerImpl->WriteText();
        // ........
    }
    virtual void SendPicture(Image image){
        messagerImpl->DrawShape();
    }
};

class MessagerPerfect : public Messager{
public:
    MessagerPerfect(MessagerImpl msgImpl):Messager(msgImpl){}

    virtual void Login(string username, string password){
        messagerImpl->PlaySound();
        // ********
        messagerImpl->Connect();
        // ........
    }
    virtual void SendMessage(string message){
        messagerImpl->PlaySound();
        // ********
        messagerImpl->WriteText();
        // ........
    }
    virtual void SendPicture(Image image){
        messagerImpl->PlaySound();
        // ********
        messagerImpl->DrawShape();
        // ........
    }
};

void Process(){
    MessagerImpl * messagerImpl = new PCMessagerImpl();
    Messager * messagerLite = new MessagerLite(messagerImpl); // PC Lite版
    Messager * messagerPerfect = new MessagerPerfect(messagerImpl); // PC Perfect版  
}

要点

• Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自纬度的变化，即“子类化”它们。
• Bridge模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
• Bridge模式的应用一般在“两个非常强的变化维度”，有时一个类也有多于两个的变化维度，这时可以使用Bridge的扩展模式。

总结

桥模式意思就是不要把所有的功能封装到一个类之中，而是应该根据它们的功能关系将每一类相关功能封装到一个类中。