装饰者模式
感觉装饰者是一种比较重要的设计模式，它本身是通过组合的思想来实现的。
先考虑一个简单的例子：比如发送消息给某一个账号，刚开始只有短信一种方式：
class SMSNotifier {
func send(String msg) {}
}
此时新增了两种方式：EMail和微信
class EMailNotifier {
func send(String msg){}
}
class WechatNotifier {
func send(String msg){}
}
之后需要同时支持三种中的两种发消息的方式，就需要新增3种新的类型：
class SMSEMailNotifier {
func send(String msg){}
}
class SMSWechatNotifier {
func send(String msg){}
}
class EmailWechatNotifier {
func send(String msg){}
}
当前这种设计，随着需要支持的通讯类型增加，所需要的类型也会越来越多。并且如果其中一种基本通讯方式发送消息的逻辑发生变化，影响的可能是好几个类。比如Email 变化可能除了Email类本身还会导致其他支持Email的类型(比如EmailWechartNotifier)也需要跟着修改。所以，这种设计对扩展不够友好的。除了现在这种方式，可能还会想到通过继承来实现。但在很多语言中是无法同时继承多个类，并且继承也解决不了类型增加的问题，所以继承的方式也不是特别好的方案。
如果有一种能够根据实际需求灵活组装类型的方案就好了，同时不需要增加新的类型。此时装饰者就比较合适了，其UML结构如下图所示：
装饰者模式.png
上图中Concrete Component只实现了Component接口，它是用来被Decorator进行封装的对象。而Decorator就是用来装饰其他对象的装饰者，同时也可以被其他Decorator装饰。对来调用方Client而言，它只关心Component接口，至于具体内部有多少装饰者对象，并不需要了解。
装饰者有几个重要的特点：
1.装饰者里包含了被装饰的对象和装饰者对象，一个对象既可能是被装饰者的对象也可能是装饰者。
2.2.对接口进行了统一的封装和抽象，被装饰的对象和装饰者对象都需要实现Component接口。对于装饰者而言，可以与任何实现Component接口的对象进行组合。
3.在装饰者对象中，通过组合的方式引用了被装饰的Component对象。在实际接口excute方法的实现中，它包含装饰者自己的业务逻辑，同时也会调用Component对象的excute方法。通过这种方式，其实是实现了对代码的分层处理。把不同的业务逻辑封装到了不同的装饰者类中。
4.对于使用方来说，面向的是对同一个接口的依赖，当业务逻辑方式变化的时候，除了装饰者初始化的逻辑发生变化，调用Component excute方法的代码不需要更改。
1和2实现了可以根据业务需要把不同的装饰者组合起来使用，增加或者减少装饰的层次。
再看一个实际的例子：在读写一些数据时候，除了数据本身的存储和获取可能还会包含一些其他操作，比如加解密，压缩和解压缩等。
先创建一个统一的数据业务的抽象接口DataSource，里面有write和read两个基本方法：
protocol DataSource {
func read() -> String
func write(c: String)
}
FileDataSource是读写文件的类，只包含最基本的IO操作：
class FileDataSource: DataSource {
var content: String = ""
func read() -> String {
return content
}
func write(c: String) {
content = c
}
}
现在创建一个装饰者的基类，他比FileDataSource多了一个实现DataSource接口类型的字段。它本身被用做其他具体装饰者的基类，所以read和write方法没有其他内容，直接调用ds的read和write方法：
class DataSourceDecorator: DataSource {
var ds: DataSource
init(data: DataSource) {
ds = data
}
func read() -> String {
return ds.read()
}
func write(c: String) {
ds.write(c: c)
}
}
接着创建两个具体的装饰者对象：用于加解密，压缩和解压缩的装饰者，它们在读取数据之后进行解密和解压缩，在存储数据之前进行加密和压缩。
class EncryptionDecorator: DataSourceDecorator {
override func read() -> String {
let s = self.ds.read()
print("解密...")
return s
}
override func write(c: String) {
print("加密...")
self.ds.write(c: c)
}
}
class CompressionDecorator: DataSourceDecorator {
override func read() -> String {
let c = self.ds.read()
print("解压缩...")
return c
}
override func write(c: String) {
print("压缩...")
self.ds.write(c: c)
}
}
测试代码，能够看到加入不同的装饰者之后的变化：
func testDecorator() {
var d:DataSource = FileDataSource()
d.write(c: "测试数据")
print("\(d.read())")
print("\n")
d = EncryptionDecorator(data: d)
d.write(c: "测试数据")
print("\(d.read())")
print("\n")
d = CompressionDecorator(data: d)
d.write(c: "测试数据")
print("\(d.read())")
}
