设计模式【8】——装饰器模式(Decorator 模式)

文章目录

  • 前言
  • 一、装饰器模式(Decorator 模式)
  • 二、具体源码
    • 1.Decorator.h
    • 2.Decorator.cpp
    • 3.main.cpp
  • 三、运行结果
  • 总结


前言

在系统程序设计与开发过程中,会经常遇到需要为一个已经定义好的类添加新的功能或者操作,通常的情况下我们可以定义一个新类继承自定义好的类。但是这样会带来一个问题:当具体子类要添加新的功能函数时,就必须向其父类添加一个相应的功能函数的抽象接口,否则无法通过父类指针实现调用功能。因此,处于高层的父类就承载了太多的抽象接口,而且所有继承自父类的子类都不可避免继承了这些接口,但是部分功能可能并不是该子类所需要的。另一方面,通过继承的方式解决的话还增加了系统的复杂性,因为随着更多子类的继承,继承的深度会变得很深,系统也会越来越复杂。
而 Decorator 通过组合的方式实现了新功能的添加,从而规避了上述问题。


一、装饰器模式(Decorator 模式)

ConcreteComponent 和 Decorator 需要有同样的接 口,因此ConcreteComp onent 和 Decorator 有着一个共同的父类。这里有人会问,让 Decorator 直接维护一个指向 ConcreteComponent 引用(指针)不就可以达到同样的效果。当然我们可以通过这种方式实现,但是我们要避免这种实现方式,因为通过这种方式只能为这个特定的 ConcreteComponent 提供修饰操作了,当有了一个新的ConcreteComponent 时,我们还必须新建一个 Decorator 来 实现。因此降低了程序的可扩展性。但是通过ConcreteComponent 和 Decorator 有一个公共基类,这样就可以利用多态的思想来实现:只要是 Component 型别的对象都可以提供修饰操作的类,即使新建N个Component 型别的类 ConcreteComponent,也可以通过一个 Decorator 类搞定,保证了程序的可扩展性与简洁性。当然如果你只用给 Component 型别类添加一种修饰,则 Decorator 这个基类就不是很必要了,只需声明一个对应的装饰类即可。UML图如下:
设计模式【8】——装饰器模式(Decorator 模式)_第1张图片

二、具体源码

1.Decorator.h

代码如下(示例):

#pragma once

#ifndef _DECORATOR_H_ 
#define _DECORATOR_H_ 

#include

//公共的基类,保证接口一致
class Component
{
public:

  virtual ~Component();
  virtual void Operation();

protected:

  Component();

private:
};

//具体的被装饰类
class ConcreteComponent :public Component
{
public:

  ConcreteComponent();
  ~ConcreteComponent();
  //实现具体的功能
  void Operation();

protected:
private:
};

//装饰类基类
class Decorator :public Component
{
public:

  Decorator(Component* com);
  virtual ~Decorator();
  void Operation();

protected:

  Component* _com;
private:
};

//装饰类的具体实现
class ConcreteDecorator :public Decorator
{
public:

  ConcreteDecorator(Component* com);
  ~ConcreteDecorator();
  void Operation();
  //新添加的功能,在Operation内被调用,起到“装饰”的作用
  void AddedBehavior();

protected:
private:
};

#endif //_DECORATOR_H_

2.Decorator.cpp

代码如下(示例):

#include "Decorator.h"


Component::Component()
{
}

Component::~Component()
{
}

void Component::Operation()
{
}

ConcreteComponent::ConcreteComponent()
{
}

ConcreteComponent::~ConcreteComponent()
{
}

void ConcreteComponent::Operation()
{
  std::cout << "ConcreteComponent operation..." << std::endl;
}

Decorator::Decorator(Component* com)
{
  this->_com = com;
}

Decorator::~Decorator()
{
  delete _com;
}

void Decorator::Operation()
{
}

ConcreteDecorator::ConcreteDecorator(Component* com) :Decorator(com)
{
}

ConcreteDecorator::~ConcreteDecorator()
{
}

void ConcreteDecorator::AddedBehavior()
{
  std::cout << "ConcreteDecorator::AddedBehacior...." << std::endl;
}

///具体装饰子类,通过调用内部AddedBehavior函数,起到装饰作用
void ConcreteDecorator::Operation()
{
  _com->Operation();
  this->AddedBehavior();
}

3.main.cpp

代码如下(示例):

#include "Decorator.h" 

int main(int argc, char* argv[])
{
  //定义相应的被装饰类与装饰类
  Component* com = new ConcreteComponent();
  Decorator* dec = new ConcreteDecorator(com);

  dec->Operation();

  delete dec;
  return 0;
}

三、运行结果

Decorator 模式运行结果如下:
设计模式【8】——装饰器模式(Decorator 模式)_第2张图片


总结

Decorator 模式除了采用组合的方式取得了比采用继承方式更好的效果,Decorator 模式还给设计带来一种“即用即付”的方式来添加职责。在开发过程中,为了多态,通过父类指针指向其具体子类,但是这就带来另外一个问题,当具体子类要添加新的职责,就必须向其父类添加一个这个职责的抽象接口,否则是通过父类指针是调用不到这个方法了。这样处于高层的父类就承载了太多的特征(方法),并且继承自这个父类的所有子类都不可避免继承了父类的这些接口,但是可能这并不是这个具体子类所需要的。而在Decorator 模式提供了一种较好的解决方法,当需要添加一个操作的时候就可以通过
Decorator 模式来解决,你可以一步步添加新的职责。
Decorator 模式和 Proxy 模式的相似的地方在于它们都拥有一个指向其他对象的引用(指针),即通过组合的方式来为对象提供更多操作(或者 Decorator 模式)间接性(Proxy 模式)。但是他们的区别是,Decorator 模式会提供使用其作为代理的对象一样接口,使用代理类将其操作都委托给 Proxy 直接进行。


本文参考《设计模式精解-GoF 23 种设计模式解析附 C++实现源码》,对内容进行整理,方便大家学习。如想学习详细内容,请参考此书。

你可能感兴趣的:(设计模式,设计模式,装饰器模式,uml)