設計模式大結局

偶然看到了這篇講設計模式的文章,很好理解,看完了之後自己總結概況了一下。結尾附上原文地址。

六大原則:

1、單一職責原則:一個類或一個方法只專注於一件事

2、里氏替換原則:子類繼承父類實現父類方法時,最好不要對於方法直接進行修改和擴展,方法可以增加,但最好不要對於方法內部實現直接進行擴展。

3、依賴顛倒原則:接口或者抽象類不要依賴基類,要以接口的形式存在

4、接口隔離原則:一個類不需要去實現它本不需要的接口或接口中的方法,適當的結合業務場景去拆分接口會讓實現類更健康

5、迪米特法則:高內聚、低耦合;只依賴和自己有強關聯性的類,不要將一個業務中所有的對象都依賴在一個類中

6、開閉原則:保持對於擴展的開放性、減弱對於修改的開放性;簡單地說當業務是多變的時,儘量保證當變化時去新增子類或者實現類對於功能進行個性化擴展而不是修改原有現行業務代碼。

五大創建型模式:

1、單例模式:整個系統單個實例,自行私有實例化並向其他模塊提供實例;多線程懶漢模式要考慮線程安全性。

2、工廠模式:子類對於實例的創建進行擴展。其實就是符合開閉原則的實例化。

3、抽象工廠模式:工廠模式是對於一個類多層次的實例化擴展,而抽象工廠是利用工廠模式對於多個類的多層次實例化擴展。

4、建造者模式:將複雜的對象實例化過程進行封裝,讓調用者只關心結果

5、原型模式:藉助Cloneable 接口和clone()實現對於對象的合理利用,避免多次實例化對於內存的過大開銷。

十一大行爲模式:

1、模版方法:將操作的具體實現延伸到子類,父類保持固定的調用結構

2、中介者模式:在直接依賴的對象直接增加一層中介,弱化依賴,例如view->controller->model

3、命令模式:在上傳下達的業務場景中,可以將行爲抽象出來,削弱強依賴關係,命令做中介。

4、責任鏈模式:在多流程/多階段的業務場景中,將業務邏輯進行封裝,調用時只關注對象本身,類似於web開發中的多個Filter的調用

5、策略模式:將多個算法和業務邏輯封裝成兩個對象,以調用的方式進行組合/切換,常結合工廠模式。

6、迭代器模式:當集合被封裝於對象中時,在需要遍歷的場景中,不直接訪問集合,而使用迭代器作爲抽象來訪問,降低耦合。

7、觀察者模式:一個對象的改變會觸發其他相關對象的改變,比如:消息隊列的消費和hibernate設置外鍵後的關聯update和delete

8、狀態模式:將流程狀態的判斷轉換成多個狀態對象對於狀態的業務方法的不同的實現。

9、備忘錄模式:對於一個可能需要回滾的對象,用一個對象來做回收記錄

10、解釋器模式:利用接口擴展性實現語言的解釋(hibernate-SQL解釋器)

11、訪問者模式:如果C對象的業務流程需要根據A、B不同的的值來遍歷判斷時利用接口來擴展抽象出來。

七大結構型模式:

1、適配器模式:把兩個無法關聯的類相結合,使A對外暴露成B,參考java IO

2、橋接模式:抽象層次對象之間相互依賴,降低實現的耦合程度

3、組合模式:a.安全模式:抽象層只定義共通方法,特殊方法由實現層自己實現;b.透明模式:抽象層定義全部方法,實現層對於不需要的方法做空實現。

4、裝飾模式:在父類和子類的繼承關係中增加一層裝飾器,子類super之後再進行各自實現,此時左右子類及父類皆可以被裝飾,而裝飾行爲又不會入侵父類或者子類代碼。

5、外觀模式:對於實現細節的封裝,使其變化不影響外部的調用。

6、享元模式:封裝對象的創建,複用對象不再次去創建,減少資源浪費。

7、靜態代理模式:兩個類實現同一個接口,A類的A方法對於B類的A方法進行封裝,調用A類A方法時,即實現對於B類的代理。

原文鏈接:https://juejin.im/post/5ceb37a76fb9a07f0870737a?utm_source=gold_browser_extension

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章