作者：小傅哥
博客：https://bugstack.cn
沉澱、分享、成長，讓自己和他人都能有所收穫！
一、前言
對於代碼你有編程感覺嗎
很多人寫代碼往往是沒有編程感覺的，也就是除了可以把功能按照固定的流程編寫出流水式的代碼外，很難去思考整套功能服務的擴展性和可維護性。尤其是在一些較大型的功能搭建上，比較缺失一些駕馭能力，從而導致最終的代碼相對來說不能做到盡善盡美。
江洋大盜與江洋大偷
兩個本想描述一樣的意思的詞，只因一字只差就讓人覺得一個是好牛，一個好搞笑。往往我們去開發編程寫代碼時也經常將一些不恰當的用法用於業務需求實現中，當卻不能意識到。一方面是由於編碼不多缺少較大型項目的實踐，另一方面是不思進取的總在以完成需求為目標缺少精益求精的工匠精神。
書從來不是看的而是用的
在這個學習資料幾乎爆炸的時代，甚至你可以輕易就獲取幾個T的視頻，小手輕輕一點就收藏一堆文章，但卻很少去看。學習的過程從不只是簡單的看一遍就可以，對於一些實操性的技術書籍，如果真的希望學習到知識，那麼一定是把這本書用起來而絕對不是看起來。
二、開發環境
- JDK 1.8
- Idea + Maven
- 涉及工程三個，可以通過關注公眾號：
bugstack蟲洞棧，回復源碼下載獲取(打開獲取的鏈接，找到序號18)
| 工程 | 描述 |
|---|---|
| itstack-demo-design-9-00 | 場景模擬工程；模擬單點登錄類 |
| itstack-demo-design-9-01 | 使用一坨代碼實現業務需求 |
| itstack-demo-design-9-02 | 通過設計模式優化改造代碼，產生對比性從而學習 |
三、裝飾器模式介紹
初看上圖感覺裝飾器模式有點像俄羅斯套娃、某眾汽車，而裝飾器的核心就是再不改原有類的基礎上給類新增功能。不改變原有類，可能有的小夥伴會想到繼承、AOP切面，當然這些方式都可以實現，但是使用裝飾器模式會是另外一種思路更為靈活，可以避免繼承導致的子類過多，也可以避免AOP帶來的複雜性。
你熟悉的場景很多用到裝飾器模式
new BufferedReader(new FileReader(""));，這段代碼你是否熟悉，相信學習java開發到字節流、字符流、文件流的內容時都見到了這樣的代碼，一層嵌套一層，一層嵌套一層，字節流轉字符流等等，而這樣方式的使用就是裝飾器模式的一種體現。
四、案例場景模擬
在本案例中我們模擬一個單點登錄功能擴充的場景
一般在業務開發的初期，往往內部的ERP使用只需要判斷賬戶驗證即可，驗證通過後即可訪問ERP的所有資源。但隨着業務的不斷髮展，團隊里開始出現專門的運營人員、營銷人員、數據人員，每個人員對於ERP的使用需求不同，有些需要創建活動，有些只是查看數據。同時為了保證數據的安全性，不會讓每個用戶都有最高的權限。
那麼以往使用的SSO是一個組件化通用的服務，不能在裏面添加需要的用戶訪問驗證功能。這個時候我們就可以使用裝飾器模式，擴充原有的單點登錄服務。但同時也保證原有功能不受破壞，可以繼續使用。
1. 場景模擬工程
itstack-demo-design-9-00
└── src
└── main
└── java
└── org.itstack.demo.design
├── HandlerInterceptor.java
└── SsoInterceptor.java
- 這裏模擬的是spring中的類：
HandlerInterceptor，實現起接口功能SsoInterceptor模擬的單點登錄攔截服務。 - 為了避免引入太多spring的內容影響對設計模式的閱讀，這裏使用了同名的類和方法，盡可能減少外部的依賴。
2. 場景簡述
2.1 模擬Spring的HandlerInterceptor
public interface HandlerInterceptor {
boolean preHandle(String request, String response, Object handler);
}
- 實際的單點登錄開發會基於；
org.springframework.web.servlet.HandlerInterceptor實現。
2.2 模擬單點登錄功能
public class SsoInterceptor implements HandlerInterceptor{
public boolean preHandle(String request, String response, Object handler) {
// 模擬獲取cookie
String ticket = request.substring(1, 8);
// 模擬校驗
return ticket.equals("success");
}
}
- 這裏的模擬實現非常簡單隻是截取字符串，實際使用需要從
HttpServletRequest request對象中獲取cookie信息，解析ticket值做校驗。 - 在返回的裏面也非常簡單，只要獲取到了
success就認為是允許登錄。
五、用一坨坨代碼實現
此場景大多數實現的方式都會採用繼承類
繼承類的實現方式也是一個比較通用的方式，通過繼承后重寫方法，併發將自己的邏輯覆蓋進去。如果是一些簡單的場景且不需要不斷維護和擴展的，此類實現並不會有什麼，也不會導致子類過多。
1. 工程結構
itstack-demo-design-9-01
└── src
└── main
└── java
└── org.itstack.demo.design
└── LoginSsoDecorator.java
- 以上工程結構非常簡單，只是通過
LoginSsoDecorator繼承SsoInterceptor，重寫方法功能。
2. 代碼實現
public class LoginSsoDecorator extends SsoInterceptor {
private static Map<String, String> authMap = new ConcurrentHashMap<String, String>();
static {
authMap.put("huahua", "queryUserInfo");
authMap.put("doudou", "queryUserInfo");
}
@Override
public boolean preHandle(String request, String response, Object handler) {
// 模擬獲取cookie
String ticket = request.substring(1, 8);
// 模擬校驗
boolean success = ticket.equals("success");
if (!success) return false;
String userId = request.substring(9);
String method = authMap.get(userId);
// 模擬方法校驗
return "queryUserInfo".equals(method);
}
}
- 以上這部分通過繼承重寫方法，將個人可訪問哪些方法的功能添加到方法中。
- 以上看着代碼還算比較清晰，但如果是比較複雜的業務流程代碼，就會很混亂。
3. 測試驗證
3.1 編寫測試類
@Test
public void test_LoginSsoDecorator() {
LoginSsoDecorator ssoDecorator = new LoginSsoDecorator();
String request = "1successhuahua";
boolean success = ssoDecorator.preHandle(request, "ewcdqwt40liuiu", "t");
System.out.println("登錄校驗：" + request + (success ? " 放行" : " 攔截"));
}
- 這裏模擬的相當於登錄過程中的校驗操作，判斷用戶是否可登錄以及是否可訪問方法。
3.2 測試結果
登錄校驗：1successhuahua 攔截
Process finished with exit code 0
- 從測試結果來看滿足我們的預期，已經做了攔截。如果你在學習的過程中，可以嘗試模擬單點登錄並繼承擴展功能。
六、裝飾器模式重構代碼
接下來使用裝飾器模式來進行代碼優化，也算是一次很小的重構。
裝飾器主要解決的是直接繼承下因功能的不斷橫向擴展導致子類膨脹的問題，而是用裝飾器模式后就會比直接繼承顯得更加靈活同時這樣也就不再需要考慮子類的維護。
在裝飾器模式中有四個比較重要點抽象出來的點；
- 抽象構件角色(Component) –
定義抽象接口 - 具體構件角色(ConcreteComponent) –
實現抽象接口，可以是一組 - 裝飾角色(Decorator) –
定義抽象類並繼承接口中的方法，保證一致性 - 具體裝飾角色(ConcreteDecorator) –
擴展裝飾具體的實現邏輯
通過以上這四項來實現裝飾器模式，主要核心內容會體現在抽象類的定義和實現上。
1. 工程結構
itstack-demo-design-9-02
└── src
└── main
└── java
└── org.itstack.demo.design
├── LoginSsoDecorator.java
└── SsoDecorator.java
裝飾器模式模型結構
- 以上是一個裝飾器實現的類圖結構，重點的類是
SsoDecorator，這個類是一個抽象類主要完成了對接口HandlerInterceptor繼承。 - 當裝飾角色繼承接口後會提供構造函數，入參就是繼承的接口實現類即可，這樣就可以很方便的擴展出不同功能組件。
2. 代碼實現
2.1 抽象類裝飾角色
public abstract class SsoDecorator implements HandlerInterceptor {
private HandlerInterceptor handlerInterceptor;
private SsoDecorator(){}
public SsoDecorator(HandlerInterceptor handlerInterceptor) {
this.handlerInterceptor = handlerInterceptor;
}
public boolean preHandle(String request, String response, Object handler) {
return handlerInterceptor.preHandle(request, response, handler);
}
}
- 在裝飾類中有兩個重點的地方是；1)繼承了處理接口、2)提供了構造函數、3)覆蓋了方法
preHandle。 - 以上三個點是裝飾器模式的核心處理部分，這樣可以踢掉對子類繼承的方式實現邏輯功能擴展。
2.2 裝飾角色邏輯實現
public class LoginSsoDecorator extends SsoDecorator {
private Logger logger = LoggerFactory.getLogger(LoginSsoDecorator.class);
private static Map<String, String> authMap = new ConcurrentHashMap<String, String>();
static {
authMap.put("huahua", "queryUserInfo");
authMap.put("doudou", "queryUserInfo");
}
public LoginSsoDecorator(HandlerInterceptor handlerInterceptor) {
super(handlerInterceptor);
}
@Override
public boolean preHandle(String request, String response, Object handler) {
boolean success = super.preHandle(request, response, handler);
if (!success) return false;
String userId = request.substring(8);
String method = authMap.get(userId);
logger.info("模擬單點登錄方法訪問攔截校驗：{} {}", userId, method);
// 模擬方法校驗
return "queryUserInfo".equals(method);
}
}
- 在具體的裝飾類實現中，繼承了裝飾類
SsoDecorator，那麼現在就可以擴展方法；preHandle - 在
preHandle的實現中可以看到，這裏只關心擴展部分的功能，同時不會影響原有類的核心服務，也不會因為使用繼承方式而導致的多餘子類，增加了整體的靈活性。
3. 測試驗證
3.1 編寫測試類
@Test
public void test_LoginSsoDecorator() {
LoginSsoDecorator ssoDecorator = new LoginSsoDecorator(new SsoInterceptor());
String request = "1successhuahua";
boolean success = ssoDecorator.preHandle(request, "ewcdqwt40liuiu", "t");
System.out.println("登錄校驗：" + request + (success ? " 放行" : " 攔截"));
}
- 這裏測試了對裝飾器模式的使用，通過透傳原有單點登錄類
new SsoInterceptor()，傳遞給裝飾器，讓裝飾器可以執行擴充的功能。 - 同時對於傳遞者和裝飾器都可以是多組的，在一些實際的業務開發中，往往也是由於太多類型的子類實現而導致不易於維護，從而使用裝飾器模式替代。
3.2 測試結果
23:50:50.796 [main] INFO o.i.demo.design.LoginSsoDecorator - 模擬單點登錄方法訪問攔截校驗：huahua queryUserInfo
登錄校驗：1successhuahua 放行
Process finished with exit code 0
- 結果符合預期，擴展了對方法攔截的校驗性。
- 如果你在學習的過程中有用到過單點登陸，那麼可以適當在裏面進行擴展裝飾器模式進行學習使用。
- 另外，還有一種場景也可以使用裝飾器。例如；你之前使用某個實現某個接口接收單個消息，但由於外部的升級變為發送
list集合消息，但你又不希望所有的代碼類都去修改這部分邏輯。那麼可以使用裝飾器模式進行適配list集合，給使用者依然是for循環后的單個消息。
七、總結
- 使用裝飾器模式滿足單一職責原則，你可以在自己的裝飾類中完成功能邏輯的擴展，而不影響主類，同時可以按需在運行時添加和刪除這部分邏輯。另外裝飾器模式與繼承父類重寫方法，在某些時候需要按需選擇，並不一定某一個就是最好。
- 裝飾器實現的重點是對抽象類繼承接口方式的使用，同時設定被繼承的接口可以通過構造函數傳遞其實現類，由此增加擴展性並重寫方法里可以實現此部分父類實現的功能。
- 就像夏天熱你穿短褲，冬天冷你穿棉褲，雨天挨澆你穿雨衣一樣，你的根本本身沒有被改變，而你的需求卻被不同的裝飾而實現。生活中往往比比皆是設計，當你可以融合這部分活靈活現的例子到代碼實現中，往往會創造出更加優雅的實現方式。
八、推薦閱讀
- 1. 重學 Java 設計模式：實戰工廠方法模式(多種類型商品發獎場景)
- 2. 重學 Java 設計模式：實戰抽象工廠模式(替換Redis雙集群升級場景)
- 3. 重學 Java 設計模式：實戰建造者模式(裝修物料組合套餐選配場景)
- 4. 重學 Java 設計模式：實戰原型模式(多套試每人題目和答案亂序場景)
- 5. 重學 Java 設計模式：實戰橋接模式(多支付渠道「微信、支付寶」與多支付模式「刷臉、指紋」場景)
- 6. 重學 Java 設計模式：實戰組合模式(營銷差異化人群發券，決策樹引擎搭建場景)
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※別再煩惱如何寫文案,掌握八大原則!
※教你寫出一流的銷售文案?
※超省錢租車方案
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※產品缺大量曝光嗎?你需要的是一流包裝設計!
※回頭車貨運收費標準
