前言：

所有舉例都是王者榮耀相關內容(不玩王者榮耀的同學，看起來稍費勁)，為了增加閱讀興趣和方便掌握這個七大原則，舉例和原則的連接，我已經用盡畢生所學，陸陸續續寫了一周還多，不喜勿噴哈~ 有識訓的同學，記得點個贊再走…

PS：文中涉及到王者榮耀的相關名字部分使用綠色3號字標識，所以有了不知道是什么的小伙伴不用追溯，理解為一個裝備名，英雄名或者之間理解為類名都是可以的，

一，單一職責原則

1.1 舉例說明: 懲戒上單

時間：某休息日，地點：王者峽谷，人物：懲戒白起

??版本描述：這個版本雙燒流上單玩法很流行，這導致很多肉坦上單英雄都愿意攜帶懲戒，然后出紅蓮斗篷(日炎)，既能反野加快發育也能提高傷害加成…

??情景再現：敵我雙方拖至20分鐘風暴龍王現身，可以說實力相當場面十分焦灼，到了搶奪風暴龍王一局定勝負的局面，話說我方雙懲戒+白起長時間團戰控制有更大的優勢…

局內對話：

• 打野：對面要打龍逼團了，我繞后找機會切對面射手法師，你們正面拉扯下，白起嘗試搶龍
• 輔助：白起一會打團你直接入場控制開團，我保雙C（我方射手法師）
• 上路白起：好的，龍馬上快到斬殺血線了，大家準備… 我入場了，龍沒搶到
• 射手：沒事沒事，你找機會配合打野切對面魯班，魯班Si了就能打
• 上路白起：打野準備切入，魯班閃現了我大招距離不夠，打野看你的了，魯班沒閃…

5S后，對面憑借風暴龍王Buff和魯班輸出，團滅我方，帶好兵線就可以直接推掉我方水晶，取得勝利，

賽后復盤：

1. 雖然白起攜帶懲戒，但是并沒有搶到龍王，
2. 也是因為攜帶懲戒，所以團站也沒有控制到對面核心魯班七號，導致輸掉游戲，

但凡這兩點能做到任意一點也不至于輸掉游戲，

1.2 原則決議: 單一職責

??其實大多數時候，一個位置的英雄簡單一些，職責單一一些， 或許是更好的選擇，這就和設計模式中的一大原則 —— 單一職責的道理是一樣的，

??就一個類而言，應該僅有一個引起它變化的原因，我們在寫代碼的時候，很自然的就會給一個類加各種各樣的功能，比如我們寫一款游戲，一般定義一個GameManager這樣的類，于是我們就把各種各樣代碼，像處理邏輯演算法啊，訪問資料庫啊什么的都寫在這個類中，這就意味著，只要有需求改動，我們都需要修改這個游戲管理器，這其實是很差的寫法，維護麻煩，不能復用，也缺少靈活性，

??我們剛開始學習面向物件的時候，就知道面向物件的好處：可維護、可擴展、可復用、靈活性好， 所以這種寫法是需要進行改正的，

??如果一個類承擔的職責過多，就等于吧這些職責耦合在一起，一個職責的變化可能削榷訓者抑制這個類完成其他職責的能力，這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞，

• 單一職責的定義:

單一職責原則：就一個類而言，應該僅有一個引起它變化的原因，

二，開放封閉原則

2.1 舉例說明: 黃刀由來

黃色打野刀上線也有幾個版本了，簡單猜測一下它的代碼層面是如何實作的，

• 既然是打野刀，那么也就有打野刀的通用屬性（可對野怪釋放）-- 可以通過繼承實作，
• 既然是新裝備，那么也就有和其他打野刀不同的屬性 – 創建自己的類實作，

??像這種修改就符合開閉原則，對擴展開啟，對修改封閉，這時候你可能在想，我這不是說一堆廢話嘛，新添加了一個裝備可不要擴展嗎，怎么也不會在紅色打野刀類中去寫黃色打野刀的邏輯啊…

??確實是這樣，可是你想過沒有，這是在一個成熟的框架下去添加新裝備，若這是剛開始開發的程式呢？我們實作的時候不會將所有的二級打野刀都寫在一個類中，然后使用屬性或者列舉來區分當前使用的打野刀是什么，然后進行相應的邏輯處理…

3.2 原則決議: 開閉原則

??因為我們在最初寫代碼的時候，都假設需求不會產生改變，當需求變化時，我們就創建抽象來隔離以后發生同類的變化， 比如原來王者中只有兩種型別的打野刀：一個是物理傷害，一個是法術傷害的，其他各種屬性都一樣，那么此時我們寫代碼的時候完全可能將這兩個打野刀寫在一個類中，后來又來一個打野刀，它也是物理傷害的，但是屬性從加傷害變成加防御了，

??那么此時我們就需要考慮未來游戲平衡會不會再添加新的打野刀，會不會修改現有單一打野刀的屬性和數值…這時候我們的原來寫的一個類中實作的兩個打野刀，就會自然的演變成一個打野刀基類，兩個子類繼承的形式，進而有了后續添加打野刀時的添加方式，

??我們在做任何應用的時候，都不要指望一開始時需求確定，就再也不會有修改，既然需求一定會變化，那么如何在面對需求變化時，使得我們的程式可以相對容易的修改，不至于說，新需求一來，我們要洗掉原來部分代碼，重新寫一套，這就是開放封閉原則存在的意義，

??對于開發時呈現出頻繁變化的那些部分做出抽象，然而，對于程式中的每個部分都可以的進行抽象同樣是一種不好的做法，拒絕不成型的抽象和抽象本身一樣重要，

?? 開放-封閉原則是面向物件設計的核心所在，遵循這個原 則可以帶來面向物件技術所聲稱的巨大好處，也就是可維護、可擴 展、可復用、靈活性好，

• 開閉原則的定義:

開放-封閉原則：是說軟體物體（類，模塊，函式等等）應該是可以擴展，但是不可修改，

三，里氏代換原則

3.1 舉例說明: 吸血之鐮

吸血之鐮俗稱小吸血刀，可合成裝備如下：

由上圖我們可以看到小吸血刀的屬性：

• +10 物理攻擊
• +8% 物理吸血

??當我們點擊它可合成裝備時，可以看到三個裝備的屬性值都是包含 +物理攻擊 和 +百分比物理吸血 的，這就是說明，大件裝備由小件裝備合成，并且繼承了小件裝備的屬性值（多出來的部分時大件私有的），

??在游戲中不管你此時購買了末世,泣血,制裁這三個裝備中的哪一個，你都獲得了其父類小吸血刀的屬性值，在程式的角度講使用到小吸血刀(父類)的代碼完全可以被這三個裝備(子類)任意一個去替換，并且不會對游戲邏輯產生影響，這就是里氏代換原則了，

3.2 原則決議: 里氏代換

進一步描述:
??子類物件能夠替換程式中的父類物件出現的任何物件，并且保證原來的程式邏輯行為不變及正確性不被破壞，這么一說有點類似多型，多型是面向物件編程的一大特性，也是面向物件編程語言的一種語法，他是一種代碼實作思路，而里氏替換是一種設計原則，是用來指導繼承關系中子類該如何設計，子類的設計要保證在替換父類的時候，不改變原有程式邏輯以及不破壞原有程式的正確性，

回到舉例:
??若在我們上面的舉例中有一個小吸血刀類中(父類)GetAttribute()方法可以回傳當前裝備的屬性，此時父類回傳【 +10物理攻擊,+8%物理吸血】；在大吸血刀類中(子類)GetAttribute()回傳【 +100物理攻擊,+25%物理吸血】，那么此時這個子類的設計就違背了里氏替換原則，

??一個軟體物體如果使用的是一個父類的話，那么一定適用于其子類，而且察覺不出父類物件和子類物件的區別；也就是說，在程式里面，把父類都替換成它的子類，程式的行為沒有變化；簡單地說，子型別必須能夠替換掉它們的父型別，

• 里氏原則的定義:

里氏代換原則：子型別必須能夠替換掉他們的父型別，

四，迪米特法則

又稱：最少知道法則

4.1 舉例說明: 妲己抓人

時間：某休息日，地點：王者峽谷，人物：亞瑟，妲己

妲己在中路清完線，來上路幫助亞瑟抓人，

妲己一連發起三個快捷訊息：

1. 發起進攻
2. 二技能已經好了
3. 大招還有3秒

亞瑟回復快捷訊息：

• 收到

??3秒后，妲己走到上路草叢埋伏，亞瑟賣血假裝打不過，撤向妲己所在草叢，妲己一套二三一，配合亞瑟收下對面上路人頭，

??對于亞瑟來說，他只知道妲己在準備來上路抓人，技能馬上好了，這兩個訊息，他并不知道妲己技能當前加點等級，也不知道妲己還差多少錢可以出下個裝備，這些妲己的 “ 內部實作 "，亞瑟都不知道，他也不需要知道，這就是迪米特法則，

4.2 原則決議: 迪米特法則

??“迪米特法則首先強調的是前提是在類的結構設計上，每一個類都應當盡量降低成員的訪問權限；也就是說，一個類包裝好自己的private狀態，不需要別的類知道的欄位或行為就不要公開”

迪米特法則其根本思想是強調了類之間的松耦合，

• 迪米特法則的定義:

迪米特法則：如果兩個類不必彼此直接通信，那么這兩個類就不應當發生直接的相互作用，如果其中一個類需要呼叫另一個類的某個方法的話，可以通過第三者轉發這個呼叫，

五，介面分離原則

5.1 如何理解介面隔離原則？

理解“介面隔離原則”的重點是理解其中“介面”二字：

• 若把“介面”理解為面向物件中的介面，那介面的設計要盡量單一，不要讓實作類有用不到的介面函式，
  比如說：A類實作I介面，I介面中有X()，Y()兩個函式；若A類只需要用X()，那么這樣的設計是不合理的，
• 若把“介面”理解為一組介面的集合，可以是某個類別庫的介面，如果使用的類只需要呼叫其中的部分介面，那么我們需要將這部分介面隔離出來，單獨給部分呼叫者使用，

5.2 與單一職責原則的區別

• 單一職責針對的是模塊、類、介面的設計，介面隔離原則相對于單一職責原則，一方面更側重介面的設計，另一方面它的思考角度也是不同的
• 介面隔離原則則提供了一種判斷介面的職責是否單一的標準：通過呼叫者如何使用介面間接地判定，如果呼叫者只使用部分介面或部分介面的功能，那介面設計的就不夠單一，

介面隔離原則：不應該強迫物件依賴它不需要的介面，

六，依賴倒置原則

6.1 舉例說明: 電腦主板

??昨天公司美術妹子的電腦用著用著突然藍屏了，來找我幫忙看看咋回事，根據我的經驗是記憶體潭訓了，于是我打開機箱拆下記憶體條，更換插槽各種操作，最終確定了就是其中的一個記憶體潭訓了，換了個新的記憶體條，電腦成功啟動，

??能這么輕松的解決問題還是要歸功于PC的易插拔設計，不管是記憶體、顯卡、硬碟等任何部件壞了，我們只需更換壞的那個就可以了，**這種易插拔在面向物件中就是強內聚，低耦合，

?? ** 因為無論是那個廠家制造的這記憶體條，也不管它的內部實作是什么樣的，它最終都需要支持主板的插槽，這就是針對介面設計，若針對實作設計，那么很打可能我們的記憶體潭訓了，也需要更換對應的主板，

6.2 原則決議: 依賴倒置

??依賴倒置設計理念: 相對于細節的多變性，抽象的東西要檔案的多，以抽象為基礎搭建的架構比細節為基礎搭建的架構要穩定的多，依賴倒置的中心思想是面向介面編程，

??面向程序開發時，為了使得常用的代碼可以復用，一般都會吧這些常用的代碼寫成許許多多函式的程式庫，這樣我們在做新專案時，去呼叫這些低層的函式就可以了，

• 依賴倒置的定義:

依賴倒置原則：
A.高層模塊不應該依賴底層模塊，兩個都應該依賴抽象，
B.抽象不應該依賴細節，細節應該依賴抽象，

七，合成/聚合復用原則

之前我的理解是：合成復用 和 聚合復用 是兩個名字一個意思，后來具體學習了才知道，其實并不是這樣，可以說這是兩種相近的設計模式，到底是怎么回事？ 往下看看吧~

7.1 舉例說明: 兵線佇列

合成和聚合都是關聯的特殊種類：

• 聚合表示一種弱的‘擁有’關系，體現的是A物件包含B物件，但B物件不是A的物件的一部分
• 合成則表示一種強的‘擁有’關系，體現了嚴格的部分和整體的關系，部分和整體的生命周期是一致的，

??比方說：王者榮耀中的兵線，每一波兵線都由多個小兵組成，每個小兵都屬于一隊兵線，一隊兵線和多個小兵是聚合關系， 而每個小兵都有一個的武器(攻擊類)，武器和小兵是部分與整體的關系，并且他們的生命周期是相同的，于是小兵和武器就是合成關系，

7.2 原則決議: 合成/聚合復用

??合成/聚合復用的好處：優先使用物件的合成/聚合將有助于我們保存封裝每個類，并被集中在單個任務上，這樣類和類的繼承層次會保持較小規模，并且不太可能增長為不可控制打龐然大物，

• 合成/聚合復用原則的定義:

合成/聚合復用：盡量使用合成/聚合，盡量要使用類的繼承，

??文中有兩個原則的舉例說明，我實在是沒想出怎么用王者榮耀相關內容舉例分析，若你有好的想法歡迎評論區補充，

學習完了休息一下吧，走打王者去~