写在前面
　　近，接手了一个新业务，系统的架构可圈可点。但有些地方让人望而生畏，有些代码臃肿难以维护，让人不敢恭维。于是，结合了Java的开放封闭原则，对其中一部分代码进行了重构优化。
　　先来看下以前系统的老代码
ShareChannelManager.java
publicResultDO<String>shareChannel(intshareCode){
if(ShareCodeUtil.share2A(shareCode)){
//TODO，分享到A渠道的业务逻辑代码
}
if(ShareCodeUtil.share2B(shareCode)){
//TODO，分享到B渠道的业务逻辑代码
}
...渠道n...
}
　　shareChannel这个方法承载了分享渠道的主要链路逻辑。分享到各个渠道的代码都写在了一个类的方法里面，显得很臃肿，不好维护。每次添加分享的渠道，都得修改此重量级的方法。稍微手抖撸错了，会影响到其它渠道分享。同时也违背了Java的开放封闭原则。
　　介绍下Java的开放封闭原则
　　Java开放封闭原则，咋一看给人一种矛盾的feel。开放了怎么还封闭呢？不要从表面上去理解。从两个维度去思考，**开放**&***封闭**。Java的开放原则是指设计的架构具备良好的拓展性；而关闭原则是说系统的架构主链路不能随着业务迭代而大改，即便是动辄全身，也只能说明系统的架构有问题。每个系统都必须经历一个从0到1的过程，随着业务的发展，系统也可能一成不变。如何让系统的架构前瞻性、及拓展性，都是我们在日常开发中必须思考的技术点。
　　总之，Java的开放封闭原则有两个特征。
　　-对于扩展是开放的
　　-对于更改是封闭的
　　基于上述说的设计原则，如何优化分上述提到的问题
　　思路是将多个分享渠道组成链式调用。将分享动作抽象出来，分发到各个渠道去实现。
　　定义分享渠道链
publicclassShareChannelChain{
privatefinalLoggerLOG=LoggerFactory.getLogger(this.getClass());
/**
*分享渠道链
*/
privateList<ShareChannel>shareChannels;
publicResultDO<String>share(intshareCode){
for(ShareChannels:shareChannels){
ResultDO<String>r=s.share(shareCode);
}
}
　　定义分享渠道父类
　　publicinterfaceShareChannel{
　　publicResultDO<String>share(intshareCod);
　　}
　　A渠道分享
publicclassAChannelimplementsShareChannel{
@Override
publicResultDO<String>share(intshareCode){
//TODO分享A渠道逻辑
}
}
　　B渠道分享
publicclassBChannelimplementsShareChannel{
@Override
publicResultDO<String>share(intshareCode){
//TODO分享B渠道逻辑
}
}
　　将AChannel和BChannel组装成一条调用链ShareChannelChain。
<beanid="AChannel"class="com.test.AChannel">
</bean>
<beanid="BChannel"class="com.test.BChannel">
</bean>
<beanid="shareChannelChain"class="com.test.ShareChannelChain">
<propertyname="shareChannels">
<list>
<reflocal="AChannel"/>
<reflocal="BChannel"/>
</list>
</property>
</bean>
　　渠道分享主要接口
　　ShareChannelManager.java
　　publicResultDO<String>shareChannel(intshareCode){
　　ShareChannelChain.share(shareCode);
　　}
　　后来回顾下，看看优化之后架构带来的好处
　　假设有新的渠道分享业务需求，CChannel，想想我们要改动的点。这次不必改动ShareChannelManager核心类逻辑了。只需要拓展一个CChannel，实现ShareChannel接口share方法，再配置到xml即可。这种改动点风险是可以控制的，不动到核心类逻辑。