设计模式 学习笔记 之 装饰模式 Decorator(6)

之前的学习过程中 学习了单一职责类：

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

这时候关键就是划清责任。

今天就具体学习下单一职责中的装饰模式。

动机：在某些情况下我们可能会“过度的使用继承来拓展对象的功能”，由于继承为类型引入的静态特质，是的这种扩展

方式缺乏灵活性，并且随着子类的增多（扩展的功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。

如何使“对象功能的拓展”能够根据需要来动态的实现？同时便面“扩展功能的增多”带来的子类膨胀问题？

从而使得任何“功能扩展的变化”所导致的影响降低！

其实java的IO 处理就是装饰模式实现的。

接下来我们就用C++ 伪代码的 设计我们自己的 IO 代码，按照常规思路去设计的话 首先我们先来抽象接口

 然后通过不同的实体进行子类话，伪代码如下

class Stream { // 定义一组功能操作接口
public :
    virtual char Read(int number) = 0; //读取
    virtual void Seek(int positon) = 0;//定位
    virtual void Write(char date) = 0; //写
    virtual ~Stream(){
    }
};


class FileStream:public Stream{
    //文件流处理类
public :
    virtual char Read(int number) {

    }
    virtual void Seek(int positon) {

    }
    virtual void Write(char date) {

    }
};
class NetworkStrrea: public Stream{
    //网络流
public :
    virtual char Read(int number) {

    }
    virtual void Seek(int positon) {

    }
    virtual void Write(char date) {

    }
};

class MemoryStream: public Stream{
    //内存流
public :
    virtual char Read(int number) {

    }
    virtual void Seek(int positon) {

    }
    virtual void Write(char date) {

    }
};

当新的需求来了现在 需要加密的时候文件流，还需要缓冲流：

class CrytoFileStream :public FileStream
{
public :
    virtual char Read(int number) {
        //额外的加密操作……
        FileStream ::Read(number);
    }
    virtual void Seek(int positon) {
          //额外的加密操作……
        FileStream ::Seek(positon);
    }
    virtual void Write(char date) {
          //额外的加密操作……
        FileStream ::Write(date);
    }
};


class CrytoNetworkStrrea :public NetworkStrrea
{
public :
    virtual char Read(int number) {
        //额外的加密操作……
        NetworkStrrea ::Read(number);
    }
    virtual void Seek(int positon) {
          //额外的加密操作……
        NetworkStrrea ::Seek(positon);
    }
    virtual void Write(char date) {
          //额外的加密操作……
        NetworkStrrea ::Write(date);
    }
};
class CrytoMemoryStream :public MemoryStream
{
public :
    virtual char Read(int number) {
        //额外的加密操作……
        MemoryStream ::Read(number);
    }
    virtual void Seek(int positon) {
          //额外的加密操作……
        MemoryStream ::Seek(positon);
    }
    virtual void Write(char date) {
          //额外的加密操作……
        MemoryStream ::Write(date);
    }
};

class BufferFileStream :public FileStream{
//...
};
class BufferNetworkStrrea :public NetworkStrrea{
//...
};
class BufferMemoryStream :public MemoryStream{
//...
};

用了继承的方式 当新的需求去改变流的时候将会不停的继承成子类。在没有学习装饰模式之前，和容易掉进这样的陷阱。

假设我们现在要有个既有加密又有缓冲的流操作 ：

class CrytoBufferFileStream :public FileStream{
//...
};
class CrytoBufferNetworkStrrea :public NetworkStrrea{
//...
};
class CrytoBufferMemoryStream :public MemoryStream{
//...
};

就会又多出三个子类去继承  来张图：

来算下 如果这样设计下来会存在多少个 类呢   1 +n +n *m! /2   现在的 n = 2 ，m= 3； 如果n 和m 都变大了 ，

那真的是个可怕的事情。

既然知道这是个非常可怕，并将来的对维护而言肯定更加困难，

根据设计原则 组合优于继承 我们将代码重构 

class CrytoFileStream
{
    FileStream *fileStream;
public :
    virtual char Read(int number) {
        //额外的加密操作……
        fileStream->Read(number);
    }
    virtual void Seek(int positon) {
          //额外的加密操作……
        fileStream->Seek(positon);
    }
    virtual void Write(char date) {
          //额外的加密操作……
        fileStream->Write(date);
    }
};


class CrytoNetworkStream
{
    NetworkStrrea *networkStrrea;
public :
    virtual char Read(int number) {
        //额外的加密操作……
        networkStrrea->Read(number);
    }
    virtual void Seek(int positon) {
          //额外的加密操作……
       networkStrrea->Seek(positon);
    }
    virtual void Write(char date) {
          //额外的加密操作……
        networkStrrea->Write(date);
    }
};
class CrytoMemoryStream  
{
    MemoryStream *memoryStream;
public :
    virtual char Read(int number) {
        //额外的加密操作……
        memoryStream->Read(number);
    }
    virtual void Seek(int positon) {
          //额外的加密操作……
        memoryStream->Seek(positon);
    }
    virtual void Write(char date) {
          //额外的加密操作……
        memoryStream->Write(date);
    }
};

有多态意识的可以意识到， 使用组合关系的时候，使用的全是子类 ，当大部分变量是某个类型的的子类，就不用声明成子类 ，直接声明父类就好 。

也就是里氏替换原则，

我们可以把编译期的帮绑定替换成运行时的 。

class CrytoFileStream
{
    Stream *stream; //new FileStream();
public :
    virtual char Read(int number) {
        //额外的加密操作……
        stream->Read(number);
    }
    virtual void Seek(int positon) {
          //额外的加密操作……
        stream->Seek(positon);
    }
    virtual void Write(char date) {
          //额外的加密操作……
        stream->Write(date);
    }
};


class CrytoNetworkStrrea
{
     Stream *stream;
public :
    virtual char Read(int number) {
        //额外的加密操作……
        stream->Read(number);
    }
    virtual void Seek(int positon) {
          //额外的加密操作……
       stream->Seek(positon);
    }
    virtual void Write(char date) {
          //额外的加密操作……
        stream->Write(date);
    }
};
class CrytoMemoryStream  
{
    Stream *stream;
public :
    virtual char Read(int number) {
        //额外的加密操作……
        stream->Read(number);
    }
    virtual void Seek(int positon) {
          //额外的加密操作……
        stream->Seek(positon);
    }
    virtual void Write(char date) {
          //额外的加密操作……
        stream->Write(date);
    }
};

到这里以后来一次总结 ： 我们可以发现继承和组合的微妙关系 ，编译时复用，运行时去变化。

这也是我们写面向对象代码的真谛 。

仔细来看上面的代码是不是发现竟然是一样的。不一样的在哪里 就是在那个未来 多态去支持变化的。

class CrytoStream  :public Stream
{
    //为什么要继承呢？因为需要接口的规范
    Stream *stream;
public :
    virtual char Read(int number) {
        //额外的加密操作……
        stream->Read(number);
    }
    virtual void Seek(int positon) {
          //额外的加密操作……
        stream->Seek(positon);
    }
    virtual void Write(char date) {
          //额外的加密操作……
        stream->Write(date);
    }
};

class BufferStream :public Stream{
//同理 我们也可以得到一个bufferSteam 缓冲流
};

根据重构理论:如果某一个类有相同的子类就继续往上提

class DecoratorStream :public Stream
{
    Stream * stream;

};
class CrytoStream  :public DecoratorStream
{


public: 
    CrytoStream(Stream  * stream):DecoratorStream(stream){

    }

public :
    virtual char Read(int number) {
        //额外的加密操作……
        stream->Read(number);
    }
    virtual void Seek(int positon) {
          //额外的加密操作……
        stream->Seek(positon);
    }
    virtual void Write(char date) {
          //额外的加密操作……
        stream->Write(date);
    }
};

class BufferStream :public DecoratorStream{
//同理 我们也可以得到一个bufferSteam 缓冲流
public: 
    BufferStream(Stream  * stream):DecoratorStream(stream){

    }
};

通过我们重构以后

他有多少类呢 ?  1+n+1+m

为什么会有怎么大的变化能 就是因为对继承的不良使用 ，这也就是我们的动机。继承引入的静态特质，组合关系引入动态。

通过组合的关系进行支持未来的变化（多态）；

GOF 中的装饰模式的定义：

动态（组合）的给一个对象增加一些额外的职责，就增加功能而言，Decorator模式比生成子类（继承）更为灵活，

（消除重复代码&减少子类个数）。

总结：

通过采用组合的而非继承的方式，Decorator模式实现了在运行是动态扩展的功能，而且根据需求扩展多个功能。

避免了使用继承带来的“灵活性”和“子类衍生”问题。

Decorator类设计接口上表现位is-a Componet 继承关系。但是实际上为has-a Componetd的组合关系。

在代码中一旦看到这样的关系 ，我们就可以按照Decorator模式来处理。