写在前面
最近, 接手了一个新业务,系统的架构可圈可点。但有些地方让人望而生畏,有些代码臃肿难以维护,让人不敢恭维。于是,结合了Java的开放封闭原则,对其中一部分代码进行了重构优化。
先来看下以前系统的老代码
ShareChannelManager.java
public ResultDO<String> shareChannel(int shareCode) { if(ShareCodeUtil.share2A(shareCode)) { // TODO, 分享到A渠道的业务逻辑代码 } if(ShareCodeUtil.share2B(shareCode)) { // TODO, 分享到B渠道的业务逻辑代码 } ...渠道n... }
shareChannel这个方法承载了分享渠道的主要链路逻辑。分享到各个渠道的代码都写在了一个类的方法里面, 显得很臃肿, 不好维护。每次添加分享的渠道,都得修改此重量级的方法。稍微手抖撸错了, 会影响到其它渠道分享。同时也违背了Java的开放封闭原则。
介绍下Java的开放封闭原则
Java开放封闭原则, 咋一看给人一种矛盾的feel。开放了怎么还封闭呢?不要从表面上去理解。从两个维度去思考, **开放** & ***封闭**。Java的开放原则是指设计的架构具备良好的拓展性;而关闭原则是说系统的架构主链路不能随着业务迭代而大改, 即便是动辄全身,也只能说明系统的架构有问题。每个系统都必须经历一个从0到1的过程, 随着业务的发展,系统也可能一成不变。如何让系统的架构前瞻性、及拓展性,都是我们在日常开发中必须思考的技术点。
总之,Java的开放封闭原则有两个特征。
基于上述说的设计原则, 如何优化分上述提到的问题
思路是将多个分享渠道组成链式调用。将分享动作抽象出来,分发到各个渠道去实现。
定义分享渠道链
public class ShareChannelChain { private final Logger LOG = LoggerFactory.getLogger(this.getClass()); /** * 分享渠道链 */ private List<ShareChannel> shareChannels; public ResultDO<String> share(int shareCode) { for (ShareChannel s : shareChannels) { ResultDO<String> r = s.share(shareCode); } }
定义分享渠道父类
public interface ShareChannel { public ResultDO<String> share(int shareCod); }
A渠道分享
public class AChannel implements ShareChannel { @Override public ResultDO<String> share(int shareCode) { // TODO 分享A渠道逻辑 } }
B渠道分享
public class BChannel implements ShareChannel { @Override public ResultDO<String> share(int shareCode) { // TODO 分享B渠道逻辑 } }
将AChannel 和 BChannel 组装成一条调用链 ShareChannelChain。
<bean id="AChannel" class="com.test.AChannel"> </bean> <bean id="BChannel" class="com.test.BChannel"> </bean> <bean id="shareChannelChain" class="com.test.ShareChannelChain"> <property name="shareChannels"> <list> <ref local="AChannel"/> <ref local="BChannel"/> </list> </property> </bean>
渠道分享主要接口
ShareChannelManager.java
public ResultDO<String> shareChannel(int shareCode) { ShareChannelChain.share(shareCode); }
最后来回顾下,看看优化之后架构带来的好处
假设有新的渠道分享业务需求,CChannel, 想想我们要改动的点。这次不必改动ShareChannelManager核心类逻辑了。只需要拓展一个CChannel,实现ShareChannel接口share方法,再配置到xml即可。这种改动点风险是可以控制的,不动到核心类逻辑。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小牛知识库。
本文向大家介绍浅谈C#设计模式之开放封闭原则,包括了浅谈C#设计模式之开放封闭原则的使用技巧和注意事项,需要的朋友参考一下 在软件设计模式证这种不能修改,但可以扩展的思想也是最重要的设计原则,他就是开放-封闭原则 (OCP) 对于程序设计而言,怎么的设计才能面对需求的改变却可以保持相对的稳定,从而可以使得系统可以再第一个版本的基础上不断的推出新版本呢? 答案是在程序设计的时候使用开放封闭原则。
本文向大家介绍浅谈c#设计模式之单一原则,包括了浅谈c#设计模式之单一原则的使用技巧和注意事项,需要的朋友参考一下 单一原则: 程序设计时功能模块独立,功能单一更有助于维护和复用。 例如:个人计算机功能很多,如果想从中只拿出一个功能来制造一个新的东西是困难的。同时如果你的计算机开不机,同时你的计算器功能也不能用了。 在编程中如果一个类封装了太多功能和上面的结果是类似的。 单一职责原则 例1: 大家
本文向大家介绍浅谈JAVA设计模式之享元模式,包括了浅谈JAVA设计模式之享元模式的使用技巧和注意事项,需要的朋友参考一下 享元模式(Flyweight Pattern)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结构的方式。 享元模式尝试重用现有的同类对象,如果未找到匹配的对象,则创建新对象。我们将通过创建 5
本文向大家介绍浅谈C#设计模式之代理模式,包括了浅谈C#设计模式之代理模式的使用技巧和注意事项,需要的朋友参考一下 代理模式是常用的结构型设计模式之一,当无法直接访问某个对象或访问某个对象存在困难时可以通过一个代理对象来间接访问,为了保证客户端使用的透明性,所访问的真实对象与代理对象需要实现相同的接口.根据代理模式的使用目的不同,代理模式又可以分为多种类型,例如保护代理、远程代理、虚拟代理、缓冲代
本文向大家介绍浅谈Java设计模式系列-装饰器模式,包括了浅谈Java设计模式系列-装饰器模式的使用技巧和注意事项,需要的朋友参考一下 一、概述 装饰器模式作用是针对目标方法进行增强,提供新的功能或者额外的功能。 不同于适配器模式和桥接模式,装饰器模式涉及的是单方,和代理模式相同,而且目标必须是抽象的。 而实际上,装饰器模式和代理模式的实现方式基本一致,只在目标的存在上有些差别,这个后面我们具体讲
本文向大家介绍Java设计模式之Prototype原型模式,包括了Java设计模式之Prototype原型模式的使用技巧和注意事项,需要的朋友参考一下 一、场景描述 创建型模式中,从工厂方法模式,抽象工厂模式,到建造者模式,再到原型模式,我的理解是,创建对象的方式逐步从编码实现转向内存对象处理。 例如,在“仪器数据采集器”的子类/对象“PDF文件数据采集器”和“Excel文件数据采集器”的创建过程