引言
装饰模式能够实现动态的为对象添加功能，是从一个对象外部来给对象添加功能。通常有两种方式可以实现给一个类或对象增加行为：
继承机制，使用继承机制是给现有类添加功能的一种有效途径，通过继承一个现有类可以使得子类在拥有自身方法的同时还拥有父类的方法。但是这种方法是静态的，用户不能控制增加行为的方式和时机。
组合机制，即将一个类的对象嵌入另一个对象中，由另一个对象来决定是否调用嵌入对象的行为以便扩展自己的行为，我们称这个嵌入的对象为装饰器 (Decorator)
显然，为了扩展对象功能频繁修改父类或者派生子类这种方式并不可取。在面向对象的设计中，我们应该尽量使用对象组合，而不是对象继承来扩展和复用功能。装饰器模式就是基于对象组合的方式，可以很灵活的给对象添加所需要的功能。装饰器模式的本质就是动态组合。动态是手段，组合才是目的。总之，装饰模式是通过把复杂的功能简单化，分散化，然后在运行期间，根据需要来动态组合的这样一个模式。
他的设计原则是：
多用组合，少用继承。
在平时写代码时，我们应该减少类继承的使用，过多地使用类的继承会导致类数目过于庞大而变得难以维护，而使用组合可以让我们的系统更具弹性，更加容易修改和扩展。而的接下来将要讨论的装饰者模式正是使用了对象组合的方式，可以让我们在不修改原有代码的前提下，动态地给对象赋予新的职责。
种类
1、通过子类实现装饰模式
2、通过分类来实现装饰模式
实用场景
1、需要增加一些基本的功能组成其他的一些功能。
2、需要给一些类添加一些职能
3、需要给类扩展一些动态（可能会取消）的其他的功能
（需要在不影响组件对象的情况下，以动态、透明的方式给对象添加职责。当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时可以考虑使用装饰类。）
需求场景1
这里借用 《Head First 设计模式》里的一个例子。去星巴克买过咖啡的同学都知道那里有很多种类的饮料，如果我们要为星巴克开发一个结账买单的系统，那么应该怎么设计呢？
需求分析和解决方案
首先进行需求分析，星巴克里有种类繁多的咖啡，结账时我们需要知道咖啡的名称和价格。所以，我们很容易想到抽出一个咖啡基类，然后继承实现各个种类的咖啡。但是，这样做的问题是，星巴克里有几十种饮料，如果我们给每种咖啡都创建一个类，会导致类数目过于庞大，而且星巴克也在不断地推出新的品种，这会给我们系统的维护带来不小的麻烦。
接下来我们进一步分析，造成咖啡饮料价格不同的原因在于：
- 咖啡本身的种类不同（比如，咖啡可以分为浓缩咖啡（Espresso）、无咖啡因咖啡（Decaf）、深度烘焙咖啡（DarkRoast）等）。
- 咖啡里加的调料（牛奶、豆浆、抹茶、摩卡等）不同。
所以，我们可以将问题简化成：
咖啡饮料的价格 ＝ 咖啡本身的价格 ＋ 各种调料的价格
比如，Espresso Macchiato（浓缩玛奇朵）的价格 ＝ Espresso（浓缩咖啡） 的价格 ＋Milk（牛奶）的价格 + Mocha（摩卡）的价格。
我们看到，Milk 就像一个“装饰者（Decorator）”，而 Espresso 就像一个“被装饰者(Component)”，可以在“被装饰者”上添加各种“装饰者”来制作出全新口味的 Espresso 咖啡，当然也可以把“装饰者”放在其它类别的“被装饰者”上。只要对“被装饰者”和“装饰品”进行组合，我们就能制作出各种各样的咖啡。
需要格外强调的是，这里的组合要求是动态地进行组合，即装饰者与被装饰者是在运行的时候绑定，而不是写死在类里（比如继承，类继承是在编译的时候增加行为，而装饰者模式是在运行时增加行为）。在接下来装饰者模式的实现过程中，很多实现细节都是为了达到这个目标。
综合以上的分析，我们给出如下的设计结构：
分析完整个结构，我们再来看一下，当顾客点一杯咖啡时，这些类之间应该如何互相协作调用。假设顾客点了一杯 Espresso Macchiato（浓缩玛奇朵），那么系统将会开始以下的工作流程：
- 首先实例化一个被装饰者
Espresso对象，对象里包含咖啡的基本价格和名称。 - 实例化一个装饰者
Milk对象，对象里包含 milk 的价格和名称，同时让Milk对象持有Espresso对象。 - 接下来调用
Milk对象的cost()方法，这个方法会去调用Espresso的cost()方法，并将返回的价格和 milk 的价格相加，这样我们就可以得到 Espresso 配 milk 的价格。 - 实例化一个装饰者
Mocha对象，对象里包含 mocha 的价格和名称，同时让Mocha对象持有上述Milk对象。 - 最后调用
Mocha对象的cost()方法，这个方法会去调用Milk对象的cost()方法，并将返回的价格和 mocha 的价格相加，如此我们就得到了 Espresso 配 milk 和 mocha 的价格。
这样一层一层地嵌套调用是不是很像俄罗斯套娃呢？
代码实现
下面我们给出详细的代码实现：
Beverage 协议
Beverage.h
#import <Foundation/Foundation.h>
@protocol Beverage <NSObject>
@optional
- (NSString *)getName;
- (double)cost;
@end
Espresso 类
Espresso.h
#import <Foundation/Foundation.h>
#import "Beverage.h"
@interface Espresso : NSObject<Beverage>
@end
Espresso.m
#import "Espresso.h"
@implementation Espresso{
NSString *_name;
}
- (instancetype)init{
if (self = [super init]) {
_name = @"Espresso";
}
return self;
}
- (NSString *)getName{
return _name;
}
- (double)cost{
return 1.99;
}
@end
CondimentDecorator 协议
CondimentDecorator.h
#import <Foundation/Foundation.h>
#import "Beverage.h"
@protocol CondimentDecorator <Beverage>
@end
Milk 类
Milk.h
#import <Foundation/Foundation.h>
#import "Beverage.h"
#import "CondimentDecorator.h"
@interface Milk : NSObject <CondimentDecorator>
@property (strong, nonatomic)id<Beverage> beverage;
- (instancetype)initWithBeverage:(id<Beverage>) beverage;
@end
Milk.m
#import "Milk.h"
@implementation Milk{
NSString *_name;
}
- (instancetype)initWithBeverage:(id<Beverage>)beverage{
if (self = [super init]) {
_name = @"Milk";
self.beverage = beverage;
}
return self;
}
- (NSString *)getName{
return [NSString stringWithFormat:@"%@ + %@", [self.beverage getName], _name ];
}
- (double)cost{
return .30 + [self.beverage cost];
}
@end
Mocha 类
Mocha.h
#import <Foundation/Foundation.h>
#import "Beverage.h"
#import "CondimentDecorator.h"
@interface Mocha : NSObject<CondimentDecorator>
@property (strong, nonatomic)id<Beverage> beverage;
- (instancetype)initWithBeverage:(id<Beverage>) beverage;
@end
Mocha.m
#import "Mocha.h"
@implementation Mocha{
NSString *_name;
}
- (instancetype)initWithBeverage:(id<Beverage>)beverage{
if (self = [super init]) {
self.beverage = beverage;
_name = @"Mocha";
}
return self;
}
- (NSString *)getName{
return [NSString stringWithFormat:@"%@ + %@", [self.beverage getName], _name];
}
- (double)cost{
return .20 + [self.beverage cost];
}
@end
整合调用
main.m
#import <Foundation/Foundation.h>
#import "Espresso.h"
#import "DarkRoast.h"
#import "Milk.h"
#import "Mocha.h"
#import "Soy.h"
int main(int argc, const char * argv[]) {
@autoreleasepool {
id<Beverage> espresso = [[Espresso alloc]init];
NSLog(@"name: %@ \n cost: %f \n", [espresso getName], [espresso cost]);
espresso = [[Milk alloc]initWithBeverage:espresso];
espresso = [[Mocha alloc]initWithBeverage:espresso];
NSLog(@"name: %@ \n cost:%f", [espresso getName], [espresso cost]);
}
return 0;
}
需求场景2
每个早晨出门前都要穿衣打扮，根据参加的场所选择不同的服饰。
比如现在有若干衣服：运动鞋、运动裤、卫衣、衬衫、西服、皮鞋、内衣等。
提出需求: 这周分别参加公益酒会、运动会、cosplay三个活动。怎么搭配这些衣服了，设计成类如何实现？
可以这样搭配，如图
继承方式
生成3个子类分别继承Person类:
- 第一个子类styleOne，披风+红内衣
- 第二个子类styleTwo，卫衣+运动鞋+短裤
- 第三个子类styleThree，西服+皮鞋+领带
看起来很好，而且解决了问题。但是发现同样也有一些问题，
- 这些子类都是静态的、不可改变的，比如天冷了我需要加一件棉服怎么办？每个子类都要改变
- 一年四季我们穿的衣服千变万化，这样需要创建多少个子类呢？肯定是一个很恐怖的数量
一个子类
在一个子类里定义全部的功能，需要穿哪件衣服(哪个功能)就穿哪件衣服(调用对应功能)，但是这不满足单一职责原则(不同的功能不应该放在同一个类里面)，而且这个类会过于臃肿而无法维护，并且大部分功能是使用不到的，只有在相应的场景才会需要。
而且如果增加新功能也要改变这里类，也不符合开放-封闭原则。
分析&解决
通过上面的例子我们可以发现2个规律
- 第一: 穿的衣服是可以任意组合的，理论上穿几件、穿哪种类型都可以。
也就是动态添加
- 第二: 穿完一件衣服可以再穿另一件衣服，穿完一件衣服后我还是我(类型没发生变化)。穿一件衣服之前不用关心我穿没穿衣服、穿了几件衣服，穿完之后同样也是。
添加之后类型不发生变化，添加前后都可以被一致对待。也就是装饰前和装饰后
没有什么不同
为了实现这些目的，可以这样设计：
首先，声明一个抽象接口Person，它有一个show方法来展示当前的穿着打扮。具体的人(Person)实现这个接口比如黄种人(YellowMan)，show方法只输出人名，在未装饰之前就只是一个单纯的人。
然后再定义一个装饰类Decorator，它也实现接口Person，但不同的是它拥有一个具体对象(YellowMan)的引用，而且多了一个addBehavior方法，这个方法里实现对具体对象的装饰(添加职责)。
最后创建具体的Decorator类，实现具体的addBehavior方法。
把一个具体的人类(Person)传递创建一个具体的装饰类，由于装饰类(Decorator)和人类(Person)拥有相同的接口，所以它俩的对外使用是一致的。当调用show的时候，通过对具体人类(Person)的引用调用它对应的show方法，同时调用装饰方法(addBehavior)，达到了添加职责的目的。
看一下设计类图:
这样我们就可以把任意的装饰类连接起来使用，用图表示应该是这样的
有几件衣服(职责)，就创建几个装饰类，具体怎么穿就可以随意搭配了。下面看一下代码怎么写?
代码示例
抽象接口Person
@protocol Person <NSObject>
- (void)show;
@end
具体人YellowMan实现这个接口Person
#import "Person.h"
@interface YellowMan : NSObject <Person>
- (instancetype)initWithName:(NSString *)name;
- (void)show;
@end
@interface YellowMan ()
@property (nonatomic, copy) NSString *name;
@end
@implementation YellowMan
- (instancetype)initWithName:(NSString *)name
{
self = [super init];
if (self) {
_name = name;
}
return self;
}
- (void)show
{
NSLog(@"我是: %@", self.name);
}
@end
定义一个装饰类Decorator
@interface Decorator : NSObject <Person>
- (instancetype)initWithPerson:(id <Person>)person;
- (void)show;
@end
@interface Decorator ()
@property (nonatomic, strong) id <Person>person;
@end
@implementation Decorator
- (instancetype)initWithPerson:(id <Person>)person
{
self = [super init];
if (self) {
_person = person;
}
return self;
}
- (void)show
{
[self.person show];
}
@end
定义具体的装饰类: 衬衫ShirtDecorator
@interface ShirtDecorator : Decorator
@end
@implementation ShirtDecorator
- (void)show
{
[super show];
[self addBehavior];
}
- (void)addBehavior
{
NSLog(@"-- 穿衬衫");
}
@end
定义具体的装饰类: 西装SuitDecorator
@interface SuitDecorator : Decorator
@end
@implementation SuitDecorator
- (void)show
{
[super show];
[self addBehavior];
}
- (void)addBehavior
{
NSLog(@"-- 穿西装");
}
@end
其它的装饰类都类似，不再一一写了；
client调用
YellowMan *aMan = [[YellowMan alloc] initWithName:@"小明"];
ShirtDecorator *shirtA = [[ShirtDecorator alloc] initWithPerson:aMan];
SuitDecorator *suitA = [[SuitDecorator alloc] initWithPerson:shirtA];
[suitA show];
// 小李是超人，内衣穿外面
YellowMan *bMan = [[YellowMan alloc] initWithName:@"小李"];
ShirtDecorator *shirtB = [[ShirtDecorator alloc] initWithPerson:bMan];
SuitDecorator *suitB = [[SuitDecorator alloc] initWithPerson:shirtB];
UnderwearDecorator *underwear = [[UnderwearDecorator alloc] initWithPerson:suitB];
[underwear show];
运行结果:
我们发现被装饰过的对象任然和没装饰前的一样，它的功能没有发生改变，只是多了被装饰的功能，使用方式也没有发生变化。
而且被装饰后的对象还可以被继续装饰，装饰多少次和装饰顺序完全可以动态控制。
另外：也可以使用分类实现装饰模式，分类中添加的方法对类原有的方法没有不良影响，分类中的方法成为了类的一部分，并可由其子类继承。
总结
到这里我们已经对装饰者模式有了一个比较全面的了解，最后来概括一下什么是装饰者模式：
装饰者模式，是面向对象编程领域中，一种动态地往一个类中添加新的行为的设计模式。就功能而言，修饰模式相比生成子类更为灵活，这样可以给某个对象而不是整个类添加一些功能。——《设计模式：可复用面向对象软件的基础》
完整的源代码地址
Github地址: https://github.com/Zentopia/DesignPatterns
参考资料
- 《Head First 设计模式(Java)》
- 《设计模式：可复用面向对象软件的基础》
