C++设计模式_06_Decorator 装饰模式

本篇将会介绍Decorator 装饰模式，它是属于一个新的类别，按照C++设计模式_03_模板方法Template Method中介绍的划分为“单一职责”模式。
“单一职责”模式讲的是在软件组件的设计中，如果责任划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。

典型的模式包括：Decorator 和 Bridge。这是因为这两种模式在责任的问题上表现得特别突出，但不意味着其他模式没有责任问题。
本篇主要介绍Decorator 装饰模式

1. 代码演示Decorator 装饰模式

首先结合实际场景和代码进行分析
设计场景：设计一些IO库，涉及一些流操作，针对流的操作，我们具有很多需求，比如文件流、网络流、内存流等，也有对流进行加密，进行缓存等操作。

1.1 基于继承的常规思维处理

首先我们可能会想到流的设计首先需要一个基类，基类有一些例如：Read()、Seek()、Write()等方法的公共操作，作为纯虚函数，放到Stream基类中。文件流FileStream继承自Stream基类，override Read()、Seek()、Write()等虚函数。网络流NetworkStream、内存流MemoryStream操作也是类似的

当我们进行加密操作时可以发现，首先我们需要对流有个主体的操作才能加密，我们对其中的文件流进行加密，首先去继承文件流FileStream，在Read()中进行额外的加密操作，调用基类的方法FileStream::Read(number);，Seek()、Write()方法也是在其前面做额外的加密操作。

上述过程是对文件流进行加密操作，对网络流、内存流也有加密需求，也需要重复上面在文件流加密中的动作，我们可以发现加密操作是一样的，只是流的读取操作等不一样。

相应的对流的缓冲操作BufferedFileStream，也需要考虑文件流、网络流、内存流的操作，代码并未详细写

对文件流既加密又缓冲的双重操作CryptoBufferedFileStream，此处是继承了FileStream，当然有些朋友可以直接在这里继承一个