[Unity設計模式與遊戲開發]前言

前言

做了幾年開發之後,發現不同時期對設計模式的理解會不同,剛畢業的時候看《大話設計模式》的感覺就是我平時寫的代碼也就是菜鳥麼,然後菜鳥經過老鳥的指點之後對代碼進行優化,很佩服老鳥的代碼框架設計能力,但輪到自己設計功能的時候自己卻不會用設計模式,或者說當時看設計模式只是浮於表面的“懂”。再過一兩年看設計模式有了那麼一些感覺,面試的時候或許能說出幾個常用的,但還是體會的不夠深,沒能進行融會貫通。現在決定在回顧一遍設計模式,並將其跟遊戲設計和框架開發結合起來思考學習。設計模式就好比武俠裏面的高深的武功祕籍,還記得天龍八部裏有那麼一段場景,在縹緲峯的石壁上刻着北冥神功,大夥看到的時候就感覺如獲至寶,感覺是獲得了天山童姥的高級武功,然後就練了起來,除了獲得無崖子70年功力的虛竹練了之後神清氣爽其他人都感覺走火入魔渾身難受,其實我在剛畢業的時候看github上開源的框架就有這感覺,很驚歎大牛寫的框架,但自己學習起來特別吃力,頭冒虛汗,其實說到底還是因爲當初的功底不夠,設計模式我就類比成高深的武功祕籍,不同level的開發者學習它會有不同的見解和收穫。在平時工作中,時不時的也會得到老大的指點,代碼怎樣寫才更好,其實code review大廠裏面是特別重視的,尤其是頂尖大廠,code review對初級開發者來說也是進步最快的學習方式之一,因爲只有當自己寫出了不好的代碼,知道爲什麼不好,爲什麼老大指點的方法比原本自己寫的代碼好,這樣對比學習之後纔會對好代碼有更深的體會。如果沒有一個導師指點你代碼的問題,那麼你年復一年的在寫爛代碼,N年過去那你只是一個業務上的碼農,熟練工而已,難以達到架構師的水平。

設計模式理解層次

  1. 第1層:剛開始學編程不久,聽說過什麼是設計模式,或者能說出一些設計模式名詞
  2. 第2層:有很長時間的編程經驗,自己寫了很多代碼,其中用到了設計模式,但自己卻不知道
  3. 第3層:學習過了設計模式,發現自己已經在使用了,並且發現了一些新的設計模式挺好用的
  4. 第4層:閱讀了很多別人寫的源代碼和框架,在其中看到別人設計模式,並且能夠林慧設計模式的精妙和帶來的好處
  5. 第5層:代碼寫着寫着,自己都沒有意識到使用了設計模式,並且熟練的寫了出來

這就好比習武之人對應的不同的境界:
第一境界:利劍,“凌厲剛猛,無堅不摧,弱冠前以之河朔羣雄爭鋒。”
第二境界:軟劍,“紫薇軟劍,三十歲前所用,誤傷義士不詳,乃棄之深谷。”
第三境界:重劍,“重劍無鋒,大巧不工。四十歲前執之縱橫天下。”
第四境界:木劍,“四十歲後,不滯於物,草木竹石均可爲劍。”
第五境界:無劍,“自此精修,漸進於無劍勝有劍之境。”

第五境界應該是"掃地僧"那種無敵的境地,你到哪一層階段了呢?

爲什麼要學習設計模式

編碼是程序員的看家本領,大廠(BAT)這種都比較重視編程基本功,例如設計模式和算法,爲什麼呢?算法是讓我們寫出高效的代碼,而設計模式就是讓我們寫出優雅的代碼。至於什麼是優雅的代碼?就是從可擴展性、可讀性、高內聚低耦合等角度去衡量,程序天天的工作就是寫代碼,要是代碼寫不好,最低本的看家本領都練不好,對自己的工作,自己的信心或多或少都會造成一定的影響,如果寫一段好代碼,相信你會心情舒暢並且很樂意跟其他人分享。如果成天堆砌爛代碼,不僅怕被同事review而且或許會被同事dis。我們不能僅僅滿足於寫出“能用”的代碼,“能用”的代碼誰都會寫,只有寫出“好用”的代碼久而久之才能變成同事眼中的大牛,成爲最優秀的那批人。

告別寫被人吐槽的爛代碼

我自己也不是什麼大牛,曾經在一家小公司一段時間,起初因爲代碼規範的問題,例如:代碼不對齊、變量命名隨意不規範,甚至還有數字拼音類的變量等這些最基本的編碼規範問題充滿整個項目,看的特別難受,然後寫了幾十條編碼規範的文檔,最終一些同事也有所改善,不過因爲長期隨意慣了一時半會很難全部糾正。如果在工作中你看到讓你眼前一亮的代碼的時候,你會莫名的佩服同事的編碼功底,然後對其產生好感,反之,如果你看到不好的代碼的時候,你嘴上或許不會說,但心裏一定是吐槽的,哪怕這個人業務功能開發做的再快也很難讓你信服。所以我們平時要養成優化代碼的習慣,其實誰都不想寫爛代碼,限於自身變成功底或許我們無意識的寫出了爛代碼,如果被同事指出要樂於接受改正,然後在着手下代碼之前花一段時間思考一下設計,刻意鍛鍊一段時間,讓自己養成這種意識,久而久之會成爲習慣,不經意的就會寫出好的代碼,能作爲同事學習和臨摹的典範,成爲自己引以爲豪的亮點之一。

如何評價代碼的好壞

我們只有知道什麼樣的代碼是好代碼的前提下才能寫出好代碼,下面有一些專業名詞:
高內聚低耦合、簡單易用、靈活可擴展、可讀易維護、模塊化、安全性、兼容性、健壯性、可用性、穩定性等等,哪個名詞不同的可以百度查詢。只有知道這些評判標準,我們才能去評判代碼的好壞。設計模式就是基於這些標準而小結的編程範式,所以說深入理解了設計模式才能使我們寫出更好的代碼。

如何學習設計模式

我對如何學習一門技能理解就是多讀多寫多小結,讀:就是多讀書,多讀相關的文章,寫:就是多寫代碼,勤加練習,小結:小結是我特別看重的一個環節,小結其實是一個知識的回顧和整理,能夠鞏固所學並且融入自己的思考,還方便日後回看和複習。所謂好記性不如爛筆頭的說法還是有一定道理的,行業中我佩服的一些90後程序員,如樂樂,淺陌,李華明等他們都有一個共性就是特別愛寫文章小結,所以說學習的時候小結很重要。

設計模式有哪些內容

七大原則

原本下面五大原則我是死記硬背的,然後發現一段時間之後就容易忘記,其實五大原則有一個單詞solid方便記憶。

  • SOLID原則-SRP 單一職責原則
  • SOLID原則-OCP 開放封閉原則
  • SOLID原則-LSP 里氏替換原則
  • SOLID原則-ISP 接口隔離原則
  • SOLID原則-DIP 依賴倒置原則

還有兩個合成複用原則和迪米特法則,下文會對這些原則進行小結。

三大類型

由創建型、結構型、行爲型組成的23中設計模式

創建型

單例模式、抽象工廠模式、工廠模式、建造者模式、原型模式

結構型

代理模式、橋接模式、裝飾者模式、適配器模式、組合模式、外觀模式、享元模式

行爲型

觀察者模式、模板方法模式、策略模式、責任鏈模式、迭代器模式、狀態模式、訪問者模式、備忘錄模式、命令模式、解釋器模式、中介者模式。

注意:不同書籍上對分類和名稱略有差別。

參考

  • 王爭《設計模式之美》
  • 韓順平《Java設計模式》
  • 蔡升達《設計模式與遊戲完美開發》
  • 撈月亮的猴子

設計模式系列教程彙總

http://dingxiaowei.cn/tags/設計模式/

教程代碼下載

https://github.com/dingxiaowei/UnityDesignPatterns

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章