設計模式六大原則：
1.單一職責 2.開閉原則 3.里氏替換原則 4.依賴倒置原則 5.介面隔離原則 6.迪米特法則
模式總結：
1.創建型模式總結 2.結構型模式總結 3.行為型模式總結
設計模式：
創建型模式：1.簡單工廠 2.單例模式 3.原型模式 4.建造者模式
結構型模式：5.配接器模式 6.橋接模式 7.組合模式 8.裝飾器模式 9.外觀模式 10.享元模式
行為型模式：11.代理模式 12.模板方法 13.責任鏈模式 14.命令模式 15.迭代器模式 16.中介者模式
17.備忘錄模式 18.觀察者模式 19.狀態模式 20.策略模式 21.訪問者模式
六大原則:只是對我們寫代碼的一種指導性建議,也可以不遵守,按照自己風格寫,但是寫完之后,維護起來就是一團亂麻,而遵守了六大原則,就是提高代碼的穩定性 可拓展,健壯性
六個字總結就是高內聚,低耦合
為什么很多設計模式都差不多？ 解決的問題不同,所以取了不同的名字,（就像水庫抽水和放水,它們都是水沒了,一個抽水是為了抓魚,一個放水是為了泄洪,但是解決辦法都是把水減少）
一：單一職責:類的內部定義
定 義：一個類只負責一項職責,不要存在多余一個導致類變更的因素
反面例子：A類游泳池,負責游泳功能和跳水功能,當某一天,游泳功能改為跑步, 那么A類勢必要進行改造,從而影響跳水功能
解決方案：遵循單一職責,游泳就為游泳類,跳水就為跳水類
好處:類遵循單一職責,增加代碼擴展性,代碼很簡單,不一定需要遵守，方法遵循單一職責增加程式穩定性,每個方法都可以獨立演變
二：開閉原則
定 義：類,函式,模塊,開放拓展功能,關閉修改功能 因為修改的時候,你不知道有哪幾個地方呼叫它
反面例子：軟體,一個類,函式,基本都是二次開發,迭代,很少是一手代碼,對應一手程式員,所以修改會引起很大危險
解決方案：軟體需要變化的時候,盡量拓展來滿足需求,而不是直接去修改它,拓展之后的業務邏輯都是自己的,改起來so easily
三：里氏替換法則:父類與子類之間的關系
定 義：子類可以擴展父類的功能，但不能改變父類原有的功能
反面例子：繼承帶來好處,但是也帶來了弊端,當一個類被其他類繼承到時候,修改這個類,必須要考慮到所有的子類功能是否會產生問題
解決方案：
- 子類可以實作父類的抽象方法，但不能覆寫父類的非抽象方法，
- 子類中可以增加自己特有的方法，
- 當子類的方法多載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入引數更寬松，
- 當子類的方法實作父類的抽象方法時，方法的后置條件（即方法的回傳值）要比父類更嚴格，
- 子類繼承父類的時候,不要使用new這個關鍵字去隱藏
- 盡量左邊使用父類申明 父類=new 子類 不要用 子類=new子類 如果子類使用了new隱藏了方法,那么就會出現問題
四：依賴倒置
定義; 核心思想就是面向介面編程,高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象，
反面例子：三層 ui>bll>dal ui高層非常依賴bll層
解決方案： ui和bll層中間抽象一個IBll層 這樣改動bll層就不會直接印象ui層,同理dal和bll也可以抽象出一個IDAL層
五：介面隔離原則
定義：客戶端不應該依賴它不需要的介面；一個類對另一個類的依賴應該建立在最小的介面上，
反面例子：類A通過介面I依賴類B，類C通過介面I依賴類D，如果介面I對于類A和類B來說不是最小介面，則類B和類D必須去實作他們不需要的方法，
解決方案：將臃腫的介面I拆分為獨立的幾個介面 按功能劃分(介面分拆)，類去繼承多個分拆的介面(介面多繼承)，也就是采用介面隔離原則，
介面隔離原則的意義：就是需要按照業務怎么去拆分成小粒度的介面,合適自己的業務就行
六：迪米特法則： 類與類之間的聯系
定義：一個物件應該對其他物件保持最少的了解，高內聚 低耦合
反面例子：類與類之間的關系越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大，
解決方案：盡量降低類與其他類之間的耦合， 只和自己直接的類聯系 三層架構就是迪米特法則的最佳例子
創建型模式總結:關注物件的創建,把物件的創建進行轉移,復制,克隆
目的就是降低物件與物件直接的耦合
結構型模式總結: 關注類與類之間的關系,繼承,組合,依賴, 包一層,用新的類來進一步封裝原先的類
并且組合優于繼承 目的就是降低類與類直接的耦合
1.為什么組合會優于繼承？,因為子類繼承父類,父類會把所有方法都給子類,不管要不要
2.只能為單一型別服務
三種組合方式：屬性欄位注入 建構式注入 方法注入
行為型模式總結:關注物件和行為的分離
目的就是降低物件和行為直接的耦合
類與類之間的關系
孤立存在的類是沒有意義的 面向物件思想決定了類與類是互動的
類與類之間的關系的分為縱向與橫向：
縱向：層級關系，繼承與實作(is-a-kind-of) 橫向：平級關系，組合-聚合-關聯-依賴
1.簡單工廠_創建型模式：
對 象:產品類 工廠類 抽象產品類
使用條件: 復雜的物件創建 用戶不自己創建物件,而是由工廠來創建， 傳一個值給工廠,工廠給你創建對應的物件
例 子: 用戶class去工廠class買鞋class, 鞋clss是由工廠實體化的 而不是你用戶來生產的,你只需要找到工廠 說明你要買的那種鞋,工廠就是給你需要的鞋
2.工廠方法_創建型模式：
對 象:產品類 抽象產品類 工廠類 抽象工廠類
使用條件:比簡單工廠復雜的物件創建 用戶不自己創建物件,而是由抽象工廠里面的具體工廠來創建
例 子: 用戶去小米買鍵盤產品, 鍵盤產品是繼承與,抽象小米產品的, 抽象小米產品下面 有很多小米手機,紅米手機,
3.單例模式_創建型模式：
對 象: 實體化當前類的時候 只需要實體化一次
使用條件:多個物件,其需要實體化一個物件,全域只允許存在一個實體class
例 子:資料庫連接,
4.原型模式_創建型模式：
對 象: 原型類 具體原型類1.2.3 實作克隆
使用條件:有重復物件,或相同物件,不同屬性
例 子:qqvip,，qqvip每個有都有這個物件,但是每個qq vip等級不同,就會展示不同東西,
圍棋棋子物件,都是用的棋子物件,只是顏色位置不一樣
5.建造者模式_創建型模式：
對 象:指揮者 具體建造者(工人) 抽象建造者(工人) 產品
使用條件:比工廠方法更加復雜的物件創建，流程固定,
例 子: 建一棟房子, 有水泥工, 砌墻工,鋼筋工, 他們的建造流程都由指揮者控制,先造地基,再建框架,流程不能亂 工人配好水泥鋼筋產品
7.橋接模式_結構型：
class: 蘋果手機類,抽象手機類 ,系統類,抽象系統類
使用條件: 解決多維度的變化,多重繼承與變化封裝
例 子: 蘋果,華為,手機,都有自己的系統, 但是也可以刷機成,ios和andor系統, 如果手機和系統耦合太高,那么每一個系統和型號的改變,蘋果手機類就要發生改變
8.組合模式_結構型:
class:
使用條件: 適用于 樹形結構，遞回自己
例 子: 我們的C盤里面就是一個樹形結構,你不知道里面有多少個檔案夾,但是現在要找出來c盤下面A檔案里面的檔案數量 就可以用遞回實作 你只需要知道C：//A檔案盤位置
組合模式分為安全和透明模式 有父類和子類
安全:就是子類自己有遞回方法
透明:就是父類自己有遞回方法,這就造成了,子類繼承父類的時候必須繼承它的遞回方法,會報錯,需要忽略這個錯誤
9.裝飾器模式_結構型：面向切面編程 (AOP) 動態的添加功能 結構模式的巔峰之作：組合+繼承
class: 類與類直接的關系 降低耦合
使用條件: 希望能夠動態增加功能+只有調整功能只需順序
例 子: 動態的添加功能 動態的給物件添加 層級功能 每一層都是單獨的 可變順序的,就像人穿衣服一樣,每一件衣服都是獨立的,材質,品質不同,也可以先穿外套,再穿內衣
10.外觀模式_結構型:
class: UI BLL DAL
使用條件: 比較簡單,就是多一層介面,降低UI與DAL層的直接互動
例 子: 經典的三層架構, 就是避免了ui層直接訪問DAL資料層, 從而有了BLL業務邏輯層
舊有的系統與新系統之間的聯系,可以使用外觀模式, 都訪問中間facade 來避免舊有系統持續擴大,和業務邏輯的管理 減少類之間的依賴
11.享元模式_結構型:
class: 類, 抽象類 抽象類中有公用的屬性 類里面有自己私有的屬性
使用條件: 把物件相同的屬性歸于一個類,其他不同屬性通過外部類傳遞進來, 減少物件的重復創建
例 子: 就像斗地主一樣,56張牌 new56個物件,三個人就占了56個記憶體地址, 那么一個棋牌平臺估計經不起這么折騰，
他們區別就是里面的數字 花色不同，把這個提出來, new一個撲克物件, 里面包含一個類 而這個類的屬性欄位有:數字花色
6.配接器模式_結構型: 不需要在專案剛設計的時候使用 是屬于一種專案已經設計好,后期需求補救的一種方式
對 象: (江西人class,新疆人class 抽象class類) 配接器類 美國人類
使用條件: 把不能用的類,通過適配,變的可以一起使用
例 子: 江西人,新疆人都是中國人都會說中國話,但是如果想要使用美國人,那么久需要配接器(相當于翻譯人員),這樣就可以放在一起使用
12.代理模式_結構型：
對 象: 類 代理類 實作類
使用條件: 類不直接與實作類關聯,而是創建一個代理來執行，代理類不能擴展業務邏輯,代理是沒資格更改本來實作的業務邏輯,但可以擴展公共邏輯,加日志,快取之類的
例 子: 火車站售票處,彩票視窗, 不可能自己直接去火車上買吧, 當然也有這種情況,那么就會出現堵塞,權限也控制不了,還沒有秩序
快取代理:封裝一個第三方快取, 在代理里面進行快取操作 提升性能 性能提升 優先考慮快取
單例代理: 代理類里面做好單例
例外代理: 代理類里面做好例外控制
延遲代理:佇列 前端延遲加載 一切可以推遲的東西晚點再做 按需加載 類初始化的時候為空,在方法執行的時候再去實體化
權限代理:鑒權-授權-認證 CallContxt 一個寫 一個查 放在一個共享的地方
AOP：面向切面核心追求,不破壞封裝的前提下，動態擴展功能
13.模板方法_行為型：
class: 類，抽象類 定義一個抽象父類,實作通用的處理流程 對于不同業務在抽象父類提供抽象方法,由不同子類去實作
使用條件: 應對在一個長業務固定流程中,環節可擴轉變化就可以使用模板方法,對于部分相同業務在抽象父類提供虛方法,默認為父類方法,子類可重新定制個性化需求
例 子: 可變的和不可變的混在一起,把不可變的提取出來,做成公共的 同樣的車,有公共的配置,大家都是四個輪胎,一個方向盤,但是有的人的車,需要車內飾個性化定制
14. 責任鏈_行為型：
class: 請求人, 請求的資料, 審批人
使用條件: 一條請求,需要流傳到各個物件手里,但是各個物件審批順序可以變化，
可以把請求結構包裝存到一個第三方contenxt 也是責任鏈模式的標致, 審批程序中的節點動態擴展及更改
例 子: 請假審批,給主管 經理 ceo
15. 命令模式_行為型：
class: 請求者 抽象命令 具體命令, 執行者
使用條件: 需要發送一個請求,并且這個請求有相關命令,且資料很重要,需要實時備份 呼叫者將請求封裝,>請求封裝成命令物件,>最后發送給執行者,
命令>執行者 中間就可以做成異步佇列服務,保存好命令集,哪怕資料庫崩了,也可以執行命令集來恢復
例 子: 各種app付款指令>到資料庫，如果每天凌晨0點備份 萬一早上九點資料庫損壞, 那么0點-9點的這段時間 就可以用命令來執行恢復
16.迭代器_行為型：
class:
使用條件: 需要回圈的資料集合 list，陣列,提供統一訪問方式 如果不用foreach 迭代他們是需要不同的訪問方式的
例 子: foreach 就是c# 完美實作了迭代器模式
17.中介者_行為型：
class: 發送類 中介類 接收類 (用戶 角色 權限)
使用條件: 點到點需要變成點到面,
例 子: 群發訊息下班,如果人事說要下班,沒有中介者,那么需要一個個找到并通知,現在只需要通過郵件這個中介發送給大家
常見的就是我們系統程式的 用戶 角色 和UI 管理者和普通用戶展現的頁面選單不一樣 用戶擁有管理者角色 可以訪問后臺選單 但是后臺選單可以給多個角色
18.備忘錄_行為型：
class: 發起人 備忘錄(第三方容器),管理者(負責發起人的存檔和加載行為)
使用條件: 保存某種進度,備份行為
例 子: 游戲保存進度
19.觀察者_行為型：
class: 觀察者 抽象觀察者 主題 具體主題
使用條件: 發布訂閱的時候 一個介面需要把資料分發給不同的資料平臺
例 子: 委托是最好的解決方案
20.狀態_行為型：
class: context state 具體state
使用條件: 不同狀態,執行不同行為,消除龐大的分支判斷條件
例 子: 地鐵閘門，投票行為, 避免惡意刷票
21.策略_行為型：
class: contenxt 抽象演算法策略類 具體演算法策略類
使用條件: 各種運用到演算法的地方
例 子: 計算器,商場打折,營銷活動
22.訪問者_行為型：
class: 抽象客戶 普通客戶 VIp客戶 訪問者 客戶的具體行為
使用條件: 固定場景, 客戶這個型別是固定的不能變化,因為這個是最底層,
例 子: 運算式目錄樹就是使用訪問者模式,我們使用運算式目錄樹的時候 把lambda ()=> m*n+1給訪問者 他首先會使用遞回一步步進行二元化拆解放進去進去是 左邊：M*n 和右邊：+1 第一步拆解下就是 左邊M 右邊N
去酒吧, 酒保就是訪問者 當VIP客戶去酒吧的時候 酒保會自動把你帶到VIP客戶區 然后VIP客戶區 又分為 有拖的 和沒拖的 然后有拖的買1W的酒 沒拖的買啤酒 最后讓你坐下嗨皮 訪問者把你客戶需要做的 都給你拆解好了 最終你過去直接坐下就好 普通客戶來了也只需要交給酒保 直接坐下 給你安排的合理
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/8574.html
標籤：設計模式