装饰者模式

感觉装饰者是一种比较重要的设计模式，它本身是通过组合的思想来实现的。

先考虑一个简单的例子：比如发送消息给某一个账号，刚开始只有短信一种方式：

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())")
    
}

Reference: Dive Into DESIGN PATTERNS