零代碼以“王者榮耀”為例解析設計七原則，助你面試拿“五殺”

前言：

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

PS：文中涉及到王者榮耀的相關名字部分使用

綠色3號字

標識，所以有了不知道是什么的小伙伴不用追溯，理解為一個裝備名，英雄名或者直接理解為類名都是可以的。

一，單一職責原則

1.1 舉例說明: 懲戒上單

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

版本描述：這個版本雙燒流上單玩法很流行，這導致很多肉坦上單英雄都愿意攜帶

懲戒

，然后出

紅蓮斗篷(日炎)

。既能反野加快發育也能提高傷害加成…

情景再現：敵我雙方拖至20分鐘

風暴龍王

現身，可以說實力相當場面十分焦灼。到了搶奪風暴龍王一局定勝負的局面。話說我方雙懲戒+

白起

長時間團戰控制有更大的優勢…

局內對話：

打野：對面要打龍逼團了，我繞后找機會切對面射手法師，你們正面拉扯下，白起嘗試搶龍

輔助：白起一會打團你直接入場控制開團，我保雙C（我方射手法師）

上路白起：好的，龍馬上快到斬殺血線了，大家準備… 我入場了，龍沒搶到

射手：沒事沒事，你找機會配合打野切對面魯班，魯班Si了就能打

上路白起：打野準備切入，魯班閃現了我大招距離不夠，打野看你的了，魯班沒閃…

5S后，對面憑借

風暴龍王Buff

和

魯班

輸出，團滅我方。帶好兵線就可以直接推掉我方水晶，取得勝利。

賽后復盤：

雖然白起攜帶懲戒，但是并沒有搶到龍王。

也是因為攜帶懲戒，所以團站也沒有控制到對面核心魯班七號，導致輸掉游戲。

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

1.2 原則解析: 單一職責

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

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

我們剛開始學習面向對象的時候，就知道面向對象的好處：

可維護、可擴展、可復用、靈活性好。

所以這種寫法是需要進行改正的。

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

單一職責的定義:

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

二，開放封閉原則

2.1 舉例說明: 黃刀由來

黃色打野刀

上線也有幾個版本了，簡單猜測一下它的代碼層面是如何實現的。

既然是打野刀，那么也就有打野刀的通用屬性（可對野怪釋放）-- 可以通過繼承實現。

既然是新裝備，那么也就有和其他打野刀不同的屬性 – 創建自己的類實現。

像這種修改就符合開閉原則。對擴展開啟，對修改封閉。這時候你可能在想，我這不是說一堆廢話嘛。新添加了一個裝備可不要擴展嗎，怎么也不會在

紅色打野刀

類中去寫

黃色打野刀

的邏輯啊…

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

2.2 原則解析: 開閉原則

因為我們在最初寫代碼的時候，都假設需求不會產生改變。當需求變化時，我們就創建抽象來隔離以后發生同類的變化。 比如原來王者中只有兩種類型的

打野刀

：一個是物理傷害，一個是法術傷害的。其他各種屬性都一樣，那么此時我們寫代碼的時候完全可能將這兩個打野刀寫在一個類中。后來又來一個

打野刀

，它也是物理傷害的，但是屬性從加傷害變成加防御了。

那么此時我們就需要考慮未來游戲平衡會不會再添加新的

打野刀

，會不會修改現有單一打野刀的屬性和數值…這時候我們的原來寫的一個類中實現的兩個打野刀，就會自然的演變成一個打野刀基類，兩個子類繼承的形式。進而有了后續添加打野刀時的添加方式。

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

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

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

開閉原則的定義:

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

三，里氏代換原則

3.1 舉例說明: 吸血之鐮

吸血之鐮

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

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

+10 物理攻擊

+8% 物理吸血

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

在游戲中不管你此時購買了

末世,泣血,制裁

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

3.2 原則解析: 里氏代換

進一步描述:

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

回到舉例:

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

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

里氏原則的定義:

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

四，迪米特法則

又稱：最少知道法則

4.1 舉例說明: 妲己抓人

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

妲己

在中路清完線，來上路幫助

亞瑟

抓人。

妲己

一連發起三個快捷消息：

發起進攻

二技能已經好了

大招還有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 原則解析: 合成/聚合復用

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

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

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

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

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

游戲開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。