Unity游戲開發(fā)中設計模式的示例分析

這篇文章主要介紹了Unity游戲開發(fā)中設計模式的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

1.設計模式是什么

首先我們要知道，設計模式是按照了“面向?qū)ο笤O計的原則”，強調(diào)了以類、對象、繼承、組合作為軟件設計分析的方式，提出了同類問題的解決方案，并主要滿足了以下幾點要求

• 解決一再出現(xiàn)的問題

• 提出解決一般化問題的方案

• 使解決方案可以重復使用

簡而言之，設計模式重點在于“模式”二字，它如同開加盟店時，提供了一套可重復使用的策略，從選址、裝修、供貨渠道等，并且可以快速擴張。

同理當軟件開發(fā)者遇到相同問題時，不必再思考如分析和設計，可以從設計模式中直接找到對應的解決方法直接使用。這樣一來，既縮短了開發(fā)時間，又加強了軟件的穩(wěn)定性和維護性。

2.游戲開發(fā)與設計模式

在游戲開發(fā)中，我們會面臨很多問題，如下

• 需要一個極其穩(wěn)定的框架來承載千萬級用戶

• 不斷增加的游戲系統(tǒng)

• 對現(xiàn)有游戲功能的修改

• 敏捷開發(fā)

這時，我們便需要用到設計模式，因為他是先人的智慧、是已經(jīng)被驗證過的模式、不必思考新的解決方案。

設計模式已經(jīng)成為了軟件設計領域的共同語音，所以他還可以給我們減少人與人之間溝通的誤解，可以直接指明該游戲系統(tǒng)是用了什么設計模式，對于小型的游戲團隊，更是提升了系統(tǒng)的穩(wěn)定性和擴展性。

3.七大設計原則

單一職責原則

這個原則強調(diào)的是“當設計封裝一個類時，該類應該只負責一件事”

說起來好像很簡單，實際上對功能的劃分通常也是開發(fā)者最頭疼的一件事。

解決方案就是對類進行不斷的重構(gòu)，將部分功能抽成新的類，再利用組合的方式將新的類加入到原來的類中，慢慢的就會變成一個類只負責單一功能的實現(xiàn)。

開閉原則

這個原則強調(diào)的是“一個類應該對擴展開放，對修改關閉”

具體來說，對于已經(jīng)完成測試或者上線運營的功能，我們不應該再修改這個類的任何接口或者實現(xiàn)內(nèi)容，但是應該對功能的增加保持開放。

為了滿足這個原則的要求，我們需要將“方法”上升到接口，將“實現(xiàn)”下放到子類中，這樣當新增一個需求時，我們重新實現(xiàn)一個子類繼承自接口或者舊的子類，然后在新的子類中新增功能，這樣就保證了舊的功能沒有發(fā)生變化（對修改關閉），同時新增了功能（對擴展開放）。

里氏替換原則

這里強調(diào)的是“子類必須能夠替換父類”

關于這個概念，一般書中介紹的都比較抽象，也曾將困擾了許多人。筆者在此結(jié)合多方資料，說一下自己的理解。

首先里氏替換原則是繼承復用的基礎，反映了父類與子類之間的關系。

通俗的講有父類的地方，全部替換成子類，不影響程序的運行，這樣就滿足里氏替換原則。

那什么樣的子類在替換父類時，不會影響程序運行呢？

這種子類可以擴展父類的功能，但不能修改父類的原有功能。這也是對單一職責原則的補充——對擴展開放，對修改關閉。

如果違背了里氏替換原則，會讓程序出錯的概率大大提升

舉個栗子????????????

我們定義了一個父類——鳥，并且?guī)в幸粋€方法可以返回鳥的飛行高度。再定義兩個子類：麻雀、企鵝，并且企鵝重寫了返回飛行高度的方法，使得返回值為0。當外部需要獲取所有鳥類的飛行高度，并作為除數(shù)的分母使用，我們都知道0不可以作為分母，這時程序便出錯了。

這個栗子便出現(xiàn)了“子類修改父類原有功能”的禁忌，違反了里氏替換原則，也就是不能采用繼承結(jié)構(gòu)，要重新設計他們之間的關系。

依賴倒置原則

這個原則包含了兩個主題

• 高層模塊不能依賴于底層模塊，兩者都應該依賴于抽象概念

• 抽象接口不應該依賴于實現(xiàn)，而實現(xiàn)應該依賴于抽象接口

這里的抽象概念，我理解為接口，所以這是在告訴我們，要面向接口編程，不要面向?qū)崿F(xiàn)方式編程。

那為什么我們要面向接口編程呢，這里我舉一個實際生活中的栗子????????????

我們的電腦就是高層模塊，各種硬件設備就是底層模塊，我們每增加一個硬件設備（底層模塊），電腦（高層模塊）就需要設計一個新的接口來兼容設備，這樣便是高層模塊依賴于底層模塊，并且這并沒有滿足開閉原則，因為每次新增設備，都要對電腦進行修改。但是如果電腦定義了一個通用接口，每個硬件設備都遵循了接口協(xié)議，大家都可以插到同一個接口上，那電腦便不再依賴硬件設備了，并且兩者現(xiàn)在都只需要跟中間層接口溝通就好，這也就是兩者都依賴于抽象概念。

所以從這里我們能看出，依賴導致原則也是實現(xiàn)開閉原則的重要途徑之一，他的目的是通過面向接口編程，來降低類與類之間的耦合。

接口隔離原則

這里強調(diào)的是“客戶端不應該被迫使用他們用不到的接口方法”

其實就是要求我們對各個類，建立他們專用的接口，而不要試圖去建立一個龐大的接口提供給所有需要他的類去調(diào)用它。

最少知識原則（迪米特法則）

定義上說，一個類應該對其他類擁有最少的知識

翻譯成人話就是，如果兩個類之間無需直接通信，那就不要互相調(diào)用，交給第三方轉(zhuǎn)發(fā)就好了

舉個栗子????????????

公司老板不需要跟公司每個員工都直接交流，他只需要跟項目經(jīng)理交流就好，由項目經(jīng)理負責傳達老板的指示，這樣老板就擁有了對其他員工最少的知識，解除了對每個員工的依賴（耦合），現(xiàn)在他只依賴于項目經(jīng)理。至于基層人員，當然可以說開就開嘍。

但是在使用迪米特法則的時候需要反復權(quán)衡，如果使用不當，會產(chǎn)生大量中介類，使項目結(jié)構(gòu)變的混亂。

合成復用原則

其實合成復用原則講的就是如果可以用組合解決問題，就不用繼承。

也就是組合優(yōu)于繼承。

為什么組合會優(yōu)于繼承呢？

首先，如果使用了繼承，子類重寫了父類方法，就會違背里氏替換原則，會讓程序增加出錯的可能。這里合成復用原則和里氏替換原則又是相輔相成的。

其次，使用繼承，子類會依賴于父類的實現(xiàn)，這不利于類的擴展和實現(xiàn)。

最后，C#是無法使用多重繼承的，使用組合的方式會比層層繼承來的明白，利于項目的維護。

實現(xiàn)這個原則的方式也很簡單，是通過將已有的對象納入新對象中，作為新對象的成員對象來實現(xiàn)的，新對象可以調(diào)用已有對象的功能，從而達到復用。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“Unity游戲開發(fā)中設計模式的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業(yè)資訊頻道，更多相關知識等著你來學習!