浅谈Java的开放封闭原则

写在前面
最近, 接手了一个新业务,系统的架构可圈可点。但有些地方让人望而生畏,有些代码臃肿难以维护,让人不敢恭维。于是,结合了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即可。这种改动点风险是可以控制的,不动到核心类逻辑。

写在最后
我的新博客
CSDN博客经常打不开, 老博客继续维护一段时间吧~~

原文地址:https://www.cnblogs.com/chenmo-xpw/p/6649246.html