基本概念的解读
装饰模式是指在不必改变原类文件和使用继承的情况下，动态地扩展一个对象的功能。通过创建一个包装对象，也就是装饰来包裹真实的对象。装饰模式中的装饰对象和真实对象有相同的接口。这样客户端对象就能以和真实对象相同的方式和装饰对象交互，同时装饰对象包含一个真实对象的引用（reference）,装饰对象接受所有来自客户端的请求。它把这些请求转发给真实的对象。 装饰模式与继承都可以要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。 通过使用不同的具体装饰类以及这些装饰类的排列组合，可以创造出很多不同行为的组合。
Component：定义ConcreteComponent和Decorator类要实现的方法，装饰对象和真实对象的之间的通信就是通过Component实现；
ConcreteComponent：真实对象，使用ConcreteComponent的派生类提供核心功能，与Decorator是同一级别；
Decorator：具有特定装饰功能的类，用来装饰ConcreteComponent类，具体的装饰子类通过继承Decorator实现；
代码的实现
定义一个Persion类，有name这个属性，show方法展示name，如果需要添加一类是穿T恤，另一类是穿小破鞋的代码如下，创建persion基类
#import <Foundation/Foundation.h>
@interface Persion : NSObject
@property (nonatomic, strong)NSString *name;
- (void)show;
@end
#import "Persion.h"
@implementation Persion
- (void)show
{
NSLog(@"装饰的%@",self.name);
}
@end
创建一个类Finery，功能是提示这是一类好人
#import "Persion.h"
@interface Finery : NSObject
@property (nonatomic, strong)Persion *component;
- (void)show;
@end
#import "Finery.h"
@implementation Finery
- (void)show
{
if (self.component != nil) {
[self.component show];
}
NSLog(@"好人");
}
创建穿T恤的人
#import "Finery.h"
@interface TShirts : Finery
@property (nonatomic, strong)Finery *component;
@end
#import "TShirts.h"
@implementation TShirts
- (void)show
{
if (self.component != nil) {
[self.component show];
NSLog(@"穿个体恤");
}
}
@end
创建穿小破鞋的人
#import "Finery.h"
@interface Shoot : Finery
@property (nonatomic, strong)Finery *component;
@end
#import "Shoot.h"
@implementation Shoot
- (void)show
{
if (self.component != nil) {
[self.component show];
NSLog(@"穿个了小破鞋");
}
}
@end
创建穿小破鞋和穿体恤的人
Persion *persion = [[Persion alloc] init];
persion.name = @"萝卜";
Finery *fine = [[Finery alloc] init];
fine.component = persion;
TShirts *shirts = [[TShirts alloc] init];
shirts.component = fine;
[shirts show];
Shoot *shoot = [[Shoot alloc] init];
shoot.component = fine;
[shoot show];
代码中所有的继承都是为了那个show方法，如果每个类都单写的话，这些类继承NSObject即可，这样在实际的代码中就需要继承。
装饰模式和继承的区别
为什么要使用装饰模式呢？
在项目开发的过程中，当客户提出了个新的需求(这个新的需求需要对我们的某个类进行改动)，为了这个新的需求，当然我们会想到去扩展某个类，扩展类的功能我们可以使用继承和装饰来达到我们的目的。那到底我们是使用继承呢还是装饰呢？如果使用继承，那么我们贸然的就去修改这个类，势必会影响其他的类。如果使用装饰模式来解决这个问题的话，我们就可以在不修改源代码的基础上去增强这个类的功能。
扩展性非常好：在一个项目中，你会有非常多因素考虑不到，特别是业务的变更，时不时的冒出一个需求，特别是提出一个令项目大量延迟的需求时候，那种心情是…，真想骂娘！装饰模式可以给我们很好的帮助，通过装饰模式重新封装一个类，而不是通过继承来完成，简单点说，三个继承关系ClassA,ClassB,ClassC 三个类，我要在ClassB 类上增强一些功能怎么办？我想你会坚决的顶回去！不允许，对了，为什么呢？你增强的功能是修改ClassB 类中的方法吗？增加方法吗 ？对ClassC的影响呢？特别是ClassC 有多个的情况，你怎么办？这个评估的工作量就是够你受的，所以这个是不允许的，那还是要解决问题的呀，怎么办？通过建立ClassBDecorator 类来修饰ClassB，等于说是创建了一个新的类，这个对原有程序没有变更，通过扩充很好的完成了这次变更。
