Unity游戲開發(fā)中設(shè)計模式的示例分析
這篇文章主要介紹了Unity游戲開發(fā)中設(shè)計模式的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。
創(chuàng)新互聯(lián)長期為上1000家客戶提供的網(wǎng)站建設(shè)服務(wù)，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為宿城企業(yè)提供專業(yè)的成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計，宿城網(wǎng)站改版等技術(shù)服務(wù)。擁有十年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
1.設(shè)計模式是什么
首先我們要知道，設(shè)計模式是按照了“面向?qū)ο笤O(shè)計的原則”，強調(diào)了以類、對象、繼承、組合作為軟件設(shè)計分析的方式，提出了同類問題的解決方案，并主要滿足了以下幾點要求
解決一再出現(xiàn)的問題
提出解決一般化問題的方案
使解決方案可以重復(fù)使用
簡而言之，設(shè)計模式重點在于“模式”二字，它如同開加盟店時，提供了一套可重復(fù)使用的策略，從選址、裝修、供貨渠道等，并且可以快速擴張。
同理當軟件開發(fā)者遇到相同問題時，不必再思考如分析和設(shè)計，可以從設(shè)計模式中直接找到對應(yīng)的解決方法直接使用。這樣一來，既縮短了開發(fā)時間，又加強了軟件的穩(wěn)定性和維護性。
2.游戲開發(fā)與設(shè)計模式
在游戲開發(fā)中，我們會面臨很多問題，如下
需要一個極其穩(wěn)定的框架來承載千萬級用戶
不斷增加的游戲系統(tǒng)
對現(xiàn)有游戲功能的修改
敏捷開發(fā)
這時，我們便需要用到設(shè)計模式，因為他是先人的智慧、是已經(jīng)被驗證過的模式、不必思考新的解決方案。
設(shè)計模式已經(jīng)成為了軟件設(shè)計領(lǐng)域的共同語音，所以他還可以給我們減少人與人之間溝通的誤解，可以直接指明該游戲系統(tǒng)是用了什么設(shè)計模式，對于小型的游戲團隊，更是提升了系統(tǒng)的穩(wěn)定性和擴展性。
3.七大設(shè)計原則
單一職責原則
這個原則強調(diào)的是“當設(shè)計封裝一個類時，該類應(yīng)該只負責一件事”
說起來好像很簡單，實際上對功能的劃分通常也是開發(fā)者最頭疼的一件事。
解決方案就是對類進行不斷的重構(gòu)，將部分功能抽成新的類，再利用組合的方式將新的類加入到原來的類中，慢慢的就會變成一個類只負責單一功能的實現(xiàn)。
開閉原則
這個原則強調(diào)的是“一個類應(yīng)該對擴展開放，對修改關(guān)閉”
具體來說，對于已經(jīng)完成測試或者上線運營的功能，我們不應(yīng)該再修改這個類的任何接口或者實現(xiàn)內(nèi)容，但是應(yīng)該對功能的增加保持開放。
為了滿足這個原則的要求，我們需要將“方法”上升到接口，將“實現(xiàn)”下放到子類中，這樣當新增一個需求時，我們重新實現(xiàn)一個子類繼承自接口或者舊的子類，然后在新的子類中新增功能，這樣就保證了舊的功能沒有發(fā)生變化（對修改關(guān)閉），同時新增了功能（對擴展開放）。
里氏替換原則
這里強調(diào)的是“子類必須能夠替換父類”
關(guān)于這個概念，一般書中介紹的都比較抽象，也曾將困擾了許多人。筆者在此結(jié)合多方資料，說一下自己的理解。
首先里氏替換原則是繼承復(fù)用的基礎(chǔ)，反映了父類與子類之間的關(guān)系。
通俗的講有父類的地方，全部替換成子類，不影響程序的運行，這樣就滿足里氏替換原則。
那什么樣的子類在替換父類時，不會影響程序運行呢？
這種子類可以擴展父類的功能，但不能修改父類的原有功能。這也是對單一職責原則的補充——對擴展開放，對修改關(guān)閉。
如果違背了里氏替換原則，會讓程序出錯的概率大大提升
舉個栗子????????????
我們定義了一個父類——鳥，并且?guī)в幸粋€方法可以返回鳥的飛行高度。再定義兩個子類：麻雀、企鵝，并且企鵝重寫了返回飛行高度的方法，使得返回值為0。當外部需要獲取所有鳥類的飛行高度，并作為除數(shù)的分母使用，我們都知道0不可以作為分母，這時程序便出錯了。
這個栗子便出現(xiàn)了“子類修改父類原有功能”的禁忌，違反了里氏替換原則，也就是不能采用繼承結(jié)構(gòu)，要重新設(shè)計他們之間的關(guān)系。
依賴倒置原則
這個原則包含了兩個主題
高層模塊不能依賴于底層模塊，兩者都應(yīng)該依賴于抽象概念
抽象接口不應(yīng)該依賴于實現(xiàn)，而實現(xiàn)應(yīng)該依賴于抽象接口
這里的抽象概念，我理解為接口，所以這是在告訴我們，要面向接口編程，不要面向?qū)崿F(xiàn)方式編程。
那為什么我們要面向接口編程呢，這里我舉一個實際生活中的栗子????????????
我們的電腦就是高層模塊，各種硬件設(shè)備就是底層模塊，我們每增加一個硬件設(shè)備（底層模塊），電腦（高層模塊）就需要設(shè)計一個新的接口來兼容設(shè)備，這樣便是高層模塊依賴于底層模塊，并且這并沒有滿足開閉原則，因為每次新增設(shè)備，都要對電腦進行修改。但是如果電腦定義了一個通用接口，每個硬件設(shè)備都遵循了接口協(xié)議，大家都可以插到同一個接口上，那電腦便不再依賴硬件設(shè)備了，并且兩者現(xiàn)在都只需要跟中間層接口溝通就好，這也就是兩者都依賴于抽象概念。
所以從這里我們能看出，依賴導致原則也是實現(xiàn)開閉原則的重要途徑之一，他的目的是通過面向接口編程，來降低類與類之間的耦合。
接口隔離原則
這里強調(diào)的是“客戶端不應(yīng)該被迫使用他們用不到的接口方法”
其實就是要求我們對各個類，建立他們專用的接口，而不要試圖去建立一個龐大的接口提供給所有需要他的類去調(diào)用它。
最少知識原則（迪米特法則）
定義上說，一個類應(yīng)該對其他類擁有最少的知識
翻譯成人話就是，如果兩個類之間無需直接通信，那就不要互相調(diào)用，交給第三方轉(zhuǎn)發(fā)就好了
舉個栗子????????????
公司老板不需要跟公司每個員工都直接交流，他只需要跟項目經(jīng)理交流就好，由項目經(jīng)理負責傳達老板的指示，這樣老板就擁有了對其他員工最少的知識，解除了對每個員工的依賴（耦合），現(xiàn)在他只依賴于項目經(jīng)理。至于基層人員，當然可以說開就開嘍。
但是在使用迪米特法則的時候需要反復(fù)權(quán)衡，如果使用不當，會產(chǎn)生大量中介類，使項目結(jié)構(gòu)變的混亂。
合成復(fù)用原則
其實合成復(fù)用原則講的就是如果可以用組合解決問題，就不用繼承。
也就是組合優(yōu)于繼承。
為什么組合會優(yōu)于繼承呢？
首先，如果使用了繼承，子類重寫了父類方法，就會違背里氏替換原則，會讓程序增加出錯的可能。這里合成復(fù)用原則和里氏替換原則又是相輔相成的。
其次，使用繼承，子類會依賴于父類的實現(xiàn)，這不利于類的擴展和實現(xiàn)。
最后，C#是無法使用多重繼承的，使用組合的方式會比層層繼承來的明白，利于項目的維護。
實現(xiàn)這個原則的方式也很簡單，是通過將已有的對象納入新對象中，作為新對象的成員對象來實現(xiàn)的，新對象可以調(diào)用已有對象的功能，從而達到復(fù)用。
感謝你能夠認真閱讀完這篇文章，希望小編分享的“Unity游戲開發(fā)中設(shè)計模式的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，更多相關(guān)知識等著你來學習!
網(wǎng)頁題目：Unity游戲開發(fā)中設(shè)計模式的示例分析
瀏覽地址：http://jinyejixie.com/article2/gcsjic.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、ChatGPT、微信小程序、建站公司、網(wǎng)站設(shè)計公司、商城網(wǎng)站
聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)
