几种结构型的设计模式概析【上】——Bridge模式，Adapter模式，Decorator模式【C++实现】

Bridge模式适用于客户需求经常变化时的类的抽象和封装情况。在OO型的程序设计中，用户的需求变化，意味着类的重新抽象和封装，当用户的需求变化十分频繁时，类的重新抽象和封装工作也就颇为频繁，如此以来，将会增加和修改很多类。这对程序开发人员来说，无非是最大的痛苦。Bridge模式就是为此种情况而生，它将类的抽象和实现分为完全独立的两部分，然后通过聚合使两者又保持一定的联系。这与传统的抽象基类之后再继承子类的作用如出一辙，但却少了增加新类的环节，由此以来，程序员维护的类的数量就减少，代码的可读性也大大增加，最重要的是能时刻满足用户需求频繁变化的情况。以下是Bridge模式的UML图示（左边的类只负责抽象，右边的类进行具体抽象）：

以下是上图的C++代码实现：

#include <iostream>#include <string>using namespace std;class Abstraction{protected:Abstraction();~Abstraction();public:virtual void Operation()=0;};Abstraction::Abstraction(){}Abstraction::~Abstraction(){}class AbstractCmp{protected:AbstractCmp();~AbstractCmp();public:virtual void Operation()=0;};class ConcreteAbstraction:public Abstraction{public:ConcreteAbstraction();~ConcreteAbstraction();ConcreteAbstraction(AbstractCmp *abc);void Operation();private:AbstractCmp *abc;};ConcreteAbstraction::ConcreteAbstraction(){}ConcreteAbstraction::~ConcreteAbstraction(){}ConcreteAbstraction::ConcreteAbstraction(AbstractCmp *abc){this->abc=abc;}void ConcreteAbstraction::Operation(){abc->Operation();}AbstractCmp::AbstractCmp(){}AbstractCmp::~AbstractCmp(){}class ConcreteAbstractCmp:public AbstractCmp{public:ConcreteAbstractCmp();~ConcreteAbstractCmp();void Operation();};ConcreteAbstractCmp::ConcreteAbstractCmp(){}ConcreteAbstractCmp::~ConcreteAbstractCmp(){}void ConcreteAbstractCmp::Operation(){cout<<"ConcreteAbstractCmp's Operation has done..."<<endl;}int main(){AbstractCmp *acp=new ConcreteAbstractCmp();Abstraction *abc=new ConcreteAbstraction(acp);abc->Operation();return 0;}

 

Adapter模式比较容易理解，具有很好的易用性。在实际开发中，我们经常会遇到这样一种问题：为了加快软件的开发流程，我们的有些功能实现靠第三方库的支持来完成，而这些库的接口又不能很好的满足程序开发的接口规范，必须经过处理后才能更好的应用于开发。于是我们就需要用到Adapter模式。它的唯一作用就是重新封装外来实现，对外重新开放一个更符合我们开发需求的接口。以下是Adapter模式的UML图示：

以下是上图的C++代码实现：

#include <iostream>#include <string>using namespace std;class Target{protected:Target();~Target();public:virtual void Operation()=0;};Target::Target(){}Target::~Target(){}class Adaptee{public:Adaptee();~Adaptee();void AdapteeOperation();};Adaptee::Adaptee(){}Adaptee::~Adaptee(){}void Adaptee::AdapteeOperation(){cout<<"AdapteeOperation has done..."<<endl;}class Adapter:protected Adaptee,public Target{public:Adapter();~Adapter();void Operation();};Adapter::Adapter(){}Adapter::~Adapter(){}void Adapter::Operation(){this->AdapteeOperation();}int main(){Target *clt=new Adapter();clt->Operation();return 0;}

 

Decorator模式适用于子类的继承层次过深的情况，可以很巧妙的减少继承层数，并有效的的减少实现功能所需的代码量，无疑又是OO思想的一把利器。当需要对一个类增加新操作时，我们习惯的做法是将此类作为父类，然后再继承一个子类，将需要的实现放到子类中。但这样会带来一个问题，当我们需要的功能随着项目的进展而逐渐增多时，我们不得不每增加几项项操作，就继承一个子类，到了一定程度时，我们发现继承层数将会是空前的深，而且抽象基类为了实现多态， 必须为每一项操作新增一个纯虚函数。对于类似种种问题，Decorator模式给出了很好的解决方案，在抽象基类中，我们将看到虚函数是何等的少。Decorator的UML图示如下：

在上图中，Component为抽象基类，其操作只有一个Operation，对于其所指代的不同操作，将由子类ConcreteComponent来实现，当我们的需要增加新操作时，同样只需要新继承一个类，此类以Component为基类，在此基础上，实现自己的Operation，大体来看，同样是通过继承来增加新操作，但与我们平常的做法不同的是，此种方式的基类只有一个Component，继承层次只有一层，不管我们增加多少种操作，均是这样。在Decorator中通过与Component的组合来实现对Compnent的子类接口的应用。

 

以下是Decorator模式的C++代码实现：

#include <iostream>#include <string>using namespace std;class Component{protected:Component(){}~Component(){}public:virtual void Operation(){}};class ConcreteCompoment:public Component{public:ConcreteCompoment(){}~ConcreteCompoment(){}void Operation();};void ConcreteCompoment::Operation(){cout<<"ConcreteComponent's Operation has done..."<<endl;}class Decorator:public Component{protected:Decorator(){}~Decorator(){}public:void Operation();};void Decorator::Operation(){cout<<"Decorator's Operation has done..."<<endl;}class ConcreteDecorator:public Decorator{public:ConcreteDecorator(){}~ConcreteDecorator(){}ConcreteDecorator(Component *cmp){this->cmp=cmp;}public:void Operation();void AddedOperation();private:Component *cmp;};void ConcreteDecorator::AddedOperation(){cout<<"ConcreteDecorator's AddedOperation has done..."<<endl;}void ConcreteDecorator::Operation(){this->AddedOperation();cmp->Operation();}int main(){Component *cmp=new ConcreteCompoment();Decorator *dec=new ConcreteDecorator(cmp);dec->Operation();return 0;}