怎么看一个网站用什么系统做的,上海装修公司排名10大家装公司,建设网上银行网站,wordpress邮件客户端目录 一、场景二、面对场景中的新需求#xff0c;我们怎么办#xff1f;1、暴力法#xff1a;直接修改原有的代码。2、子类继承法#xff1a;既然要增强行为#xff0c;那我搞一个子类#xff0c;覆写不就完事了#xff1f;3、装饰器模式 三、对装饰器模式的思考1、从代… 目录 一、场景二、面对场景中的新需求我们怎么办1、暴力法直接修改原有的代码。2、子类继承法既然要增强行为那我搞一个子类覆写不就完事了3、装饰器模式 三、对装饰器模式的思考1、从代码结构上来看咋和代理模式这么像呢2、设计原则 设计模式 一、场景
在Java中提供某种功能/服务给客户端应用层的类去使用一般都是先定义接口然后实现该接口。
// 应用层
Component
public class DataSourceApplication {Autowiredprivate 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 {Overridepublic void writeData(String data) {System.out.println([FileDataSourceImpl.writeData]);}Overridepublic String readData() {System.out.println([FileDataSourceImpl.readData]);return FileDataSourceImpl.readData;}
}这时候产品经理要求写入数据前要先加密读出数据后要解密。
二、面对场景中的新需求我们怎么办
1、暴力法直接修改原有的代码。
Service
public class FileDataSourceImpl implements DataSource {Overridepublic void writeData(String data) {// 对数据加密...System.out.println([FileDataSourceImpl.writeData]);}Overridepublic String readData() {System.out.println([FileDataSourceImpl.readData]);// 对数据进行解密...return FileDataSourceImpl.readData;}
}虽然这种做法存在一些问题但在公司可能很普遍…不然屎山怎么形成的 问题1之前辛苦写的单测都白费了。虽然并不是所有程序员都会写单测 问题2逻辑耦合数据的读写和数据的加密从客观上来说是相互独立的逻辑。 如果我们耦合在一起那么方法会越来越冗长逻辑也越来越不清晰。例如产品经理又改需求了要求支持多种加密算法。
2、子类继承法既然要增强行为那我搞一个子类覆写不就完事了
Primary
Service
public class EncryptFileDataSourceImpl extends FileDataSourceImpl {Overridepublic void writeData(String data) {// 对数据进行加密String encryptedData null;...super.writeData(encryptedData);System.out.println([EncryptFileDataSourceImpl.writeData]);}Overridepublic 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 {Overridepublic void writeData(String data) {System.out.println([FileDataSourceImpl.writeData] 写入数据);}Overridepublic String readData() {return [FileDataSourceImpl.readData] 读取数据;}
}public class EncryptDataSourceImpl implements DataSource {private DataSource dataSource;public EncryptDataSourceImpl(DataSource dataSource) {this.dataSource dataSource;}Overridepublic void writeData(String data) {System.out.println([EncryptFileDataSourceImpl.writeData] 加密数据);dataSource.writeData(data);}Overridepublic 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;}Overridepublic void writeData(String data) {System.out.println([CompressDataSourceImpl.writeData] 压缩数据);dataSource.writeData(data);}Overridepublic String readData() {System.out.println(dataSource.readData());return [CompressDataSourceImpl.readData] 解压数据;}
}Configuration
public class DataSourceConfig {Beanpublic 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 {Beanpublic 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 DataSource2持有被装饰的类如上述的private DataSource dataSource;3增强接口的方法 代理模式【详见对代理模式的理解】 1实现和被代理类一样的接口2持有被代理的类3增强接口的方法 像太像了 真的是这样吗 看看客户端是如何使用的吧~ 装饰器模式我们要根据需求“装饰”出接口对应的实现类。 通过层层套娃丰富基础功能。结合上文从基本的写入数据功能丰富为压缩数据 - 加密数据 - 写入数据。 代理模式接口原本的实现类是类A代理后客户端真正使用的是实现类B通常客户端感知不到这种变化。 一图胜前言 一个接口的实现类从逻辑上说存在组合逻辑例如 加密数据 写入数据压缩数据 写入数据压缩数据 加密数据 写入数据 如果采用继承的方式会导致定义很多子类那么用组合吧用装饰器模式吧【Java的io便是这种场景~】
2、设计原则 设计模式
我也学了一阵子设计模式了已经感受到设计模式的局限性了。以上文为例如果我们拿到的FileDataSourceImpl已经是一坨屎山了里面写入数据的逻辑并不纯粹那么通过装饰器模式丰富写入数据的能力可能会出问题例如写入数据前做了一些特殊处理需求是我们先做特殊处理再加密后写入使用装饰器模式就变成了先加密然后特殊处理再写入。。此时还不如暴力法来得简洁高效。 破罐子破摔世界是熵增的… 因此设计模式非常依赖场景。场景稍微变一下设计模式就失效了… 而真正有用的是设计模式遵循的设计原则以及背后的终极奥义高内聚低耦合。
