寫在前面
最近, 接手了一個新業務,系統的架構可圈可點。但有些地方讓人望而生畏，有些代碼臃腫難以維護，讓人不敢恭維。于是，結合了Java的開放封閉原則，對其中一部分代碼進行了重構優化。
先來看下以前系統的老代碼
ShareChannelManager.java
|
1
2
3
4
5
6
7
8
9
10
11
12
|
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的開放封閉原則有兩個特征。
- - 對于擴展是開放的
- - 對于更改是封閉的
基于上述說的設計原則, 如何優化分上述提到的問題
思路是將多個分享渠道組成鏈式調用。將分享動作抽象出來，分發到各個渠道去實現。
定義分享渠道鏈
|
1
2
3
4
5
6
7
8
9
10
11
12
|
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); } } |
定義分享渠道父類
|
1
2
3
|
public interface ShareChannel { public ResultDO<String> share(int shareCod);} |
A渠道分享
|
1
2
3
4
5
6
7
|
public class AChannel implements ShareChannel { @Override public ResultDO<String> share(int shareCode) { // TODO 分享A渠道邏輯 }} |
B渠道分享
|
1
2
3
4
5
6
7
|
public class BChannel implements ShareChannel { @Override public ResultDO<String> share(int shareCode) { // TODO 分享B渠道邏輯 }} |
將AChannel 和 BChannel 組裝成一條調用鏈 ShareChannelChain。
|
1
2
3
4
5
6
7
8
9
10
11
12
|
<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
|
1
2
3
|
public ResultDO<String> shareChannel(int shareCode) { ShareChannelChain.share(shareCode);} |
最后來回顧下，看看優化之后架構帶來的好處
假設有新的渠道分享業務需求，CChannel, 想想我們要改動的點。這次不必改動ShareChannelManager核心類邏輯了。只需要拓展一個CChannel，實現ShareChannel接口share方法，再配置到xml即可。這種改動點風險是可以控制的，不動到核心類邏輯。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：http://www.cnblogs.com/chenmo-xpw/p/6649246.html
