目录
- 一、场景
- 二、面对场景中的新需求，我们怎么办？
- 1、暴力法：直接修改原有的代码。
- 2、子类继承法：既然要增强行为，那我搞一个子类，覆写不就完事了？
- 3、装饰器模式
- 三、对装饰器模式的思考
- 1、从代码结构上来看，咋和代理模式这么像呢？
- 2、设计原则 >> 设计模式
一、场景
- 在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）实现和被装饰类一样的接口（如上述的：
- 代理模式：【详见：对代理模式的理解】
- （1）实现和被代理类一样的接口
- （2）持有被代理的类
- （3）增强接口的方法
像，太像了！
- 真的是这样吗？
- 看看客户端是如何使用的吧~
装饰器模式：我们要根据需求，“装饰”出接口对应的实现类。- 通过层层套娃，丰富基础功能。结合上文，从基本的写入数据功能，丰富为：压缩数据 -> 加密数据 -> 写入数据。
代理模式：接口原本的实现类是类A，代理后，客户端真正使用的是实现类B（通常，客户端感知不到这种变化）。
- 看看客户端是如何使用的吧~
- 一图胜前言：
- 一个接口的实现类，从逻辑上说，存在
组合逻辑，例如：- 加密数据 + 写入数据
- 压缩数据 + 写入数据
- 压缩数据 + 加密数据 + 写入数据
- 如果采用继承的方式，会导致定义很多子类，那么用组合吧！用装饰器模式吧！【Java的io便是这种场景~】
- 一个接口的实现类，从逻辑上说，存在
2、设计原则 >> 设计模式
- 我也学了一阵子设计模式了，已经感受到设计模式的局限性了。以上文为例，如果我们拿到的FileDataSourceImpl已经是一坨屎山了，里面写入数据的逻辑并不纯粹，那么，通过装饰器模式丰富写入数据的能力可能会出问题（例如，写入数据前做了一些特殊处理；需求是我们先做特殊处理，再加密后写入；使用装饰器模式就变成了，先加密，然后特殊处理，再写入。）。此时，还不如暴力法来得简洁高效。
破罐子破摔，世界是熵增的…
- 因此，设计模式非常依赖场景。场景稍微变一下，设计模式就失效了… 而真正有用的是，设计模式遵循的设计原则，以及背后的终极奥义：
高内聚，低耦合。
