手机端网站思路北京seo网站开发

前言

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

典型模式：

• Decorator 装饰模式
• Bridge 桥模式

1. Decorator

1.1 模式介绍

在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。

如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响将为最低？

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

——《设计模式》GoF

1.2 模式代码

1.2.1 问题代码

//业务操作
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 NetworkStream :public Stream{
public:virtual char Read(int number){//读网络流}virtual void Seek(int position){//定位网络流}virtual void Write(char data){//写网络流}};class MemoryStream :public Stream{
public:virtual char Read(int number){//读内存流}virtual void Seek(int position){//定位内存流}virtual void Write(char data){//写内存流}};//扩展操作
class CryptoFileStream :public FileStream{
public:virtual char Read(int number){//额外的加密操作...FileStream::Read(number);//读文件流}virtual void Seek(int position){//额外的加密操作...FileStream::Seek(position);//定位文件流//额外的加密操作...}virtual void Write(byte data){//额外的加密操作...FileStream::Write(data);//写文件流//额外的加密操作...}
};class CryptoNetworkStream : :public NetworkStream{
public:virtual char Read(int number){//额外的加密操作...NetworkStream::Read(number);//读网络流}virtual void Seek(int position){//额外的加密操作...NetworkStream::Seek(position);//定位网络流//额外的加密操作...}virtual void Write(byte data){//额外的加密操作...NetworkStream::Write(data);//写网络流//额外的加密操作...}
};class CryptoMemoryStream : public MemoryStream{
public:virtual char Read(int number){//额外的加密操作...MemoryStream::Read(number);//读内存流}virtual void Seek(int position){//额外的加密操作...MemoryStream::Seek(position);//定位内存流//额外的加密操作...}virtual void Write(byte data){//额外的加密操作...MemoryStream::Write(data);//写内存流//额外的加密操作...}
};class BufferedFileStream : public FileStream{//...
};class BufferedNetworkStream : public NetworkStream{//...
};class BufferedMemoryStream : public MemoryStream{//...
}class CryptoBufferedFileStream :public FileStream{
public:virtual char Read(int number){//额外的加密操作...//额外的缓冲操作...FileStream::Read(number);//读文件流}virtual void Seek(int position){//额外的加密操作...//额外的缓冲操作...FileStream::Seek(position);//定位文件流//额外的加密操作...//额外的缓冲操作...}virtual void Write(byte data){//额外的加密操作...//额外的缓冲操作...FileStream::Write(data);//写文件流//额外的加密操作...//额外的缓冲操作...}
};void Process(){//编译时装配CryptoFileStream *fs1 = new CryptoFileStream();BufferedFileStream *fs2 = new BufferedFileStream();CryptoBufferedFileStream *fs3 =new CryptoBufferedFileStream();}

这段问题代码违反了单一职责原则：
最开始的文件流、网络流、内存流对继承流操作没问题，但是后来需要新增加密操作、缓冲操作不应该继承自上述流，因为他们只是在流操作的基础上新增了操作而已，这样依赖会使得代码急剧膨胀，达到n!

1.2.2 重构代码

//业务操作
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 NetworkStream :public Stream{
public:virtual char Read(int number){//读网络流}virtual void Seek(int position){//定位网络流}virtual void Write(char data){//写网络流}};class MemoryStream :public Stream{
public:virtual char Read(int number){//读内存流}virtual void Seek(int position){//定位内存流}virtual void Write(char data){//写内存流}};//扩展操作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{Stream* stream;//...public:BufferedStream(Stream* stm):DecoratorStream(stm){}//...
};void Process(){//运行时装配FileStream* s1=new FileStream();CryptoStream* s2=new CryptoStream(s1);BufferedStream* s3=new BufferedStream(s1);BufferedStream* s4=new BufferedStream(s2);
}

这样设计的好处在于分隔了扩展功能和原功能，每个类实现其对应功能即可

1.3 模式类图

1.4 要点总结

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

2. Bridge

2.1 模式介绍

动机：由于某些类型的固有的实现逻辑，使得它们具有两个变化的维度，乃至多个纬度的变化。

如何应对这种“多维度的变化”？如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化，而不引入额外的复杂度？

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

——《设计模式》GoF

2.2 模式代码

2.2.1 问题代码

假设您有一个几何Shape类，它有一对子类：Circle和Square。您想扩展此类层次结构以包含颜色，因此您计划创建Red和Blue塑造子类。但是，由于您已经有两个子类，因此您需要创建四个类组合，例如BlueCircle和RedSquare。

#include <iostream>class Shape{
public:virtual ~Shape() {}virtual void ShowColor() = 0;virtual void ShowShape() = 0;
};class Circle : public Shape
{
public:virtual void ShowShape(){std::cout << "Circle" << std::endl;}
};class Square : public Shape{
public:virtual void ShowShape(){std::cout << "Circle" << std::endl;}
};class RedCircle : public Circle{
public:virtual void ShowColor(){std::cout << "Red" << std::endl;}
};class BlueCircle : public Circle{
public:virtual void ShowColor(){std::cout << "Blue" << std::endl;}
};class RedSquare: public Square{
//....
};class BlueSquare: public Square{
//....
};

在层次结构中添加新的形状类型和颜色将使其呈指数级增长。例如，要添加三角形，您需要引入两个子类，每个颜色一个。之后，添加新颜色将需要创建三个子类，每个形状类型一个。我们越往后走，情况就越糟。

2.2.2 重构代码

class IColor{
public:virtual ~IColor() {}virtual	void ShowColor() = 0;
};class Red : public IColor{
public:virtual void ShowColor(){std::cout << "Red" << std::endl;}
};
//....class IShape{
public:virtual ~IShape() {}virtual void ShowShape() = 0;IShape(IColor* color) :_color(color){}protected:IColor* _color;
};class Square :public IShape{
public:Square(IColor* color) :IShape(color){}virtual void ShowShape() {std::cout << "Square" << std::endl;}
};//....

出现此问题的原因是，我们试图在两个独立维度上扩展形状类：按形状和按颜色。这是类继承中非常常见的问题。

Bridge 模式试图通过从继承切换到对象组合来解决此问题。这意味着您将其中一个维度提取到单独的类层次结构中，以便原始类将引用新层次结构的对象，而不是将其所有状态和行为都放在一个类中。

Bridge 模式建议的解决方案
您可以通过将类层次结构转换为几个相关的层次结构来防止其爆炸式增长。

按照这种方法，我们可以将与颜色相关的代码提取到它自己的类中，该类有两个子类：Red和Blue。然后，该类获得指向其中一个颜色对象的引用字段。现在，形状可以将任何与颜色相关的工作委托给链接的颜色对象。该引用将充当和类Shape之间的桥梁。从现在开始，添加新颜色不需要更改形状层次结构，反之亦然.

2.3 模式类图

2.4 模式总结

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