对装饰器模式的理解

一、场景

• 在Java中，提供某种功能/服务给客户端（应用层的类）去使用，一般都是先定义接口，然后实现该接口。

// 应用层
@Component
public class DataSourceApplication {
    @Autowired
    private DataSource dataSource;

    public void write(String data) {
        dataSource.writeData(data);
    }

    public String read() {
        return dataSource.readData();
    }
}

// 服务层
public interface DataSource {
    void writeData(String data);
    String readData();
}

@Service
public class FileDataSourceImpl implements DataSource {
    @Override
    public void writeData(String data) {
        System.out.println("[FileDataSourceImpl.writeData]");
    }

    @Override
    public String readData() {
        System.out.println("[FileDataSourceImpl.readData]");
        return "FileDataSourceImpl.readData";
    }
}

• 这时候，产品经理要求写入数据前要先加密，读出数据后要解密。

二、面对场景中的新需求，我们怎么办？

1、暴力法：直接修改原有的代码。

@Service
public class FileDataSourceImpl implements DataSource {
    @Override
    public void writeData(String data) {
    	// 对数据加密
    	...
        System.out.println("[FileDataSourceImpl.writeData]");
    }

    @Override
    public String readData() {
        System.out.println("[FileDataSourceImpl.readData]");
        // 对数据进行解密
        ...
        return "FileDataSourceImpl.readData";
    }
}

• 虽然这种做法存在一些问题，但在公司可能很普遍…（不然屎山怎么形成的？😃）
  • 问题1：之前辛苦写的单测都白费了。（虽然并不是所有程序员都会写单测 😃）
  • 问题2：逻辑耦合，数据的读写和数据的加密，从客观上来说，是相互独立的逻辑。
    • 如果我们耦合在一起，那么方法会越来越冗长，逻辑也越来越不清晰。例如，产品经理又改需求了，要求支持多种加密算法。

2、子类继承法：既然要增强行为，那我搞一个子类，覆写不就完事了？

@Primary
@Service
public class EncryptFileDataSourceImpl extends FileDataSourceImpl {
    @Override
    public void writeData(String data) {
        // 对数据进行加密
        String encryptedData = null;
        ...
        super.writeData(encryptedData);
        
        System.out.println("[EncryptFileDataSourceImpl.writeData]");
    }

    @Override
    public String readData() {
		super.readData();
		
        // 对数据进行解密
        ...
        
        System.out.println("[EncryptFileDataSourceImpl.readData]");
        return "EncryptFileDataSourceImpl.readData";
    }
}

• 如果产品经理要求先压缩数据，再加密，最后写入数据呢？难道咱再搞一个子类？
  • 咱最好避免这种链式的继承。

3、装饰器模式

• 实现：
  • （1）压缩数据 -> 加密数据 -> 写入数据
  • （2）读取数据 -> 解密数据 -> 解压数据
• 代码：

public interface DataSource {
    void writeData(String data);
    String readData();
}

public class FileDataSourceImpl implements DataSource {
    @Override
    public void writeData(String data) {
        System.out.println("[FileDataSourceImpl.writeData] 写入数据");
    }

    @Override
    public String readData() {
        return "[FileDataSourceImpl.readData] 读取数据";
    }
}

public class EncryptDataSourceImpl implements DataSource {
    private DataSource dataSource;

    public EncryptDataSourceImpl(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    @Override
    public void writeData(String data) {
        System.out.println("[EncryptFileDataSourceImpl.writeData] 加密数据");
        dataSource.writeData(data);
    }

    @Override
    public String readData() {
        System.out.println(dataSource.readData());
        return "[EncryptFileDataSourceImpl.readData] 解密数据";
    }
}

public class CompressDataSourceImpl implements DataSource {
    private DataSource dataSource;

    public CompressDataSourceImpl(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    @Override
    public void writeData(String data) {
        System.out.println("[CompressDataSourceImpl.writeData] 压缩数据");
        dataSource.writeData(data);
    }

    @Override
    public String readData() {
        System.out.println(dataSource.readData());
        return "[CompressDataSourceImpl.readData] 解压数据";
    }
}

@Configuration
public class DataSourceConfig {
    @Bean
    public DataSource compressDataSourceImpl() {
        return new CompressDataSourceImpl(new EncryptDataSourceImpl(new FileDataSourceImpl()));
    }
}

@ComponentScan
public class Application {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(Application.class);
        DataSource dataSource = applicationContext.getBean(DataSource.class);
        dataSource.writeData("hello world");
        System.out.println("-----------------------------");
        System.out.println(dataSource.readData());
    }
}

/*
[CompressDataSourceImpl.writeData] 压缩数据
[EncryptFileDataSourceImpl.writeData] 加密数据
[FileDataSourceImpl.writeData] 写入数据
-----------------------------
[FileDataSourceImpl.readData] 读取数据
[EncryptFileDataSourceImpl.readData] 解密数据
[CompressDataSourceImpl.readData] 解压数据
*/

• 一旦产品经理要改需求了，例如：
  • （1）压缩数据 -> 写入数据
  • （2）读取数据 -> 解压数据
• 咱只要修改DataSourceConfig即可：

@Configuration
public class DataSourceConfig {
    @Bean
    public DataSource compressDataSourceImpl() {
//        return new CompressDataSourceImpl(new EncryptDataSourceImpl(new FileDataSourceImpl()));
        return new CompressDataSourceImpl(new FileDataSourceImpl());
    }
}

/*
[CompressDataSourceImpl.writeData] 压缩数据
[FileDataSourceImpl.writeData] 写入数据
-----------------------------
[FileDataSourceImpl.readData] 读取数据
[CompressDataSourceImpl.readData] 解压数据
*/

三、对装饰器模式的思考

1、从代码结构上来看，咋和代理模式这么像呢？

• 装饰器模式：
  • （1）实现和被装饰类一样的接口（如上述的：implements DataSource）
  • （2）持有被装饰的类（如上述的：private DataSource dataSource;）
  • （3）增强接口的方法
• 代理模式：【详见：对代理模式的理解】
  • （1）实现和被代理类一样的接口
  • （2）持有被代理的类
  • （3）增强接口的方法

像，太像了！

• 真的是这样吗？
  • 看看客户端是如何使用的吧~
    • 装饰器模式：我们要根据需求，“装饰”出接口对应的实现类。
      • 通过层层套娃，丰富基础功能。结合上文，从基本的写入数据功能，丰富为：压缩数据 -> 加密数据 -> 写入数据。
    • 代理模式：接口原本的实现类是类A，代理后，客户端真正使用的是实现类B（通常，客户端感知不到这种变化）。
• 一图胜前言：
  
  • 一个接口的实现类，从逻辑上说，存在组合逻辑，例如：
    • 加密数据 + 写入数据
    • 压缩数据 + 写入数据
    • 压缩数据 + 加密数据 + 写入数据
  • 如果采用继承的方式，会导致定义很多子类，那么用组合吧！用装饰器模式吧！【Java的io便是这种场景~】

2、设计原则 >> 设计模式

• 我也学了一阵子设计模式了，已经感受到设计模式的局限性了。以上文为例，如果我们拿到的FileDataSourceImpl已经是一坨屎山了，里面写入数据的逻辑并不纯粹，那么，通过装饰器模式丰富写入数据的能力可能会出问题（例如，写入数据前做了一些特殊处理；需求是我们先做特殊处理，再加密后写入；使用装饰器模式就变成了，先加密，然后特殊处理，再写入。）。此时，还不如暴力法来得简洁高效。

破罐子破摔，世界是熵增的…

• 因此，设计模式非常依赖场景。场景稍微变一下，设计模式就失效了… 而真正有用的是，设计模式遵循的设计原则，以及背后的终极奥义：高内聚，低耦合。