淺談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博客經常打不開, 老博客繼續維護一段時間吧~~