我們花了 5 篇文章學習了訊息機制的方方面面。並且完成了一個簡易訊息機制，之後整合到了我們的 MonoBehaviourSimplify 裡。 現在 MonoBehaviourSimplify 有一點框架的感覺了。因為 MonoBehaviourSimplify 在提供訊息功能的同時，決定了專案指令碼中的互動方式。而目前的這套結構，足夠用它來完成一個比較小的專案了。 訊息機制是筆者在接觸單例之後，第二次被震撼到的設計模式（觀察者模式/釋出者訂閱者模式）。而筆者在初學的時候，還不太敢去設計 MonoBehaviourSimplify 這樣的基類，因為當時總覺得自己對 MonoBehaviour 生命週期理解得不夠透徹。但是，筆者在使用訊息機制的時候遇到了很多問題，比如之前提到的，總是忘記登出訊息，從而導致遊戲閃退等各種奇怪的 bug，隨著 bug 遇到得多了，就越來越意識到自動登出訊息的重要性，而自動登出訊息最好的方式就是通過繼承基類的方式。所以就冒著風險被迫著就去寫了這麼一個類，這個類以前的名字叫做 QNode 也就是我們今天 MonoBehaviourSimplify 的前身，直到現在為止，QFramework 的核心還是通過 QNode 演變過來的類，現在叫做 QMonoBehaviour。 而在當時通過設計這麼一個基類之後，筆者就對設計父類這種形式有了很大的信心，所以就只要能加到 MonoBehaviourSipmlify 的東西就全部加進去了，一直這樣下去，理論上這樣也不會發生問題，但是後來又找到了更好的方式，學習了更好的方式之後呢，就可以分辨出來哪個適合繼承，哪個適合用方法獨立實現，而哪個適合做成更復雜的系統。不過目前的這套結構，如果各位學到這裡也沒有太大的問題，已經可以拿去做專案了。 但是如果想做出更好的庫和框架，那就最好認真看完這個專欄的文章。因為這是筆者三年框架思考的濃縮版。 而到目前為止，我們可以畫出來一個框架的結構圖了。 如下所示:  雖然東西不多，但是至少目前的我們的庫可以叫做框架了。 到這裡呢，我們還沒有去講框架、架構、庫這些東西，現在正是講這些概念的最好時機，所以從下一篇開始，我們會慢慢接觸這些概念。 在上一篇呢，我們的得到了目前庫的一個分層圖，如下:  而這個圖中，把我們的庫分成兩個部分。一部分是框架，一部分是工具/庫。 框架部分，只有一個 MonoBehaviourSimplify，而工具/庫，則是除了 MonoBehaviourSimplify 以外的全部內容。 為什麼 MonoBehaviourSimplify 是框架呢？ 我們先來看看框架是什麼？ > 框架：提供一個架構（檔案結構、約定等等），你必須遵守它，只要你遵守，那剩下的就全部處理通用需求了。 這個定義呢是來自某個 JavaScript 大神書裡寫的。筆者非常認可這個說法。 那麼 MonoBehaviourSimplify 為我們提供了怎樣的架構？ 只要我們的每個指令碼都繼承了 MonoBehaviourSimplify 就可以使用它的訊息功能，並且它的訊息功能非常方便，這個是利好的方面，我們想和某個指令碼互動，不需要獲得這個指令碼的物件，而是兩個指令碼只要約定好註冊的訊息名就好了。 所以它的推薦使用方式是，繼承。 其次，繼承了之後，編譯器會給你報錯，因為要強制實現 OnBeforeDestroy 這個方法。那麼這個就是多使用者的約束，這部分其實是屬於我們的約定部分。 框架和使用者約定好了，如果想更爽地使用 訊息功能以及簡化的 API，那麼使用者只能遵循它的用法，繼承它，並重寫 OnBeforeDestroy 方法。 那麼說到這裡，還沒有提到架構兩個字。 架構在哪裡？ 我們仔細回憶最初 MonoBehaviourSimplify 解決的是什麼問題？ 是解決指令碼之間訪問問題。 在使用 MonoBehaviourSimplify 之前，指令碼之間互動的模擬圖如下:  圖中箭頭的意思呢，是擁有指令碼引用的意思，可以理解成成員變數，說耦合性非常高。 而使用了 我們的 MonoBehaviourSimplify 之後，指令碼之間的互動模擬圖就會變成如下:  雖然我們的指令碼還是與 MsgDispatcher 耦合了，不過情況好了很多，指令碼之間就沒有耦合了。 由於繼承了 MonoBehaviourSimplify，在使用訊息功能的時候壓根感受不到 MsgDispatcher 存在。 而這就是 MonoBehaviourSimplify 提供的架構。 它提供了: * 約定: * 使用者與框架之間的約定，使用者想使用框架功能，就要遵循框架的使用規則。 * 規則: * MonoBehaviourSimplify 的規則，就是要繼承 MonoBehaviourSimplify，要覆寫 OnBeforeDestroy。 * 共識: * 使用者與框架作者，都更推薦使用訊息來處理指令碼之間訪問的問題。 而我們的 MonoBehaviourSimplify 除了提供了約定、規則、共識之外，還影響了指令碼之間的互動結構。上邊的兩張圖就是證明。 而在之前裡說約定、規則、共識有什麼用呢？ 在這裡筆者告訴大家。 架構的本質，就是約定、規則、共識。通過約定、規則、共識從而影響專案中任何東西的結構。比如專案目錄規範（規則）導致了專案檔案結構（編碼規範）導致了程式碼結構，而主程與開發者的約定就會導致專案的模組結構以及團隊結構等。總之，架構最終的目的，就是得到一個好的結構。好的目錄結構，好的程式碼結構，好的程式結構，以及好的指令碼之間互動所產生的結構，那麼什麼才算好呢？俗話說，就是弟兄們幹活幹得快乾得好，專案跑得快跑得好，這就是好的架構。 扯得有點遠了，總之，框架提供了架構，更準確地說，是一部分架構，而我們的 MonoBehaviourSimplify ，改善了指令碼之間互動的問題，針對這個問題，提供了一個指令碼之間的互動結構，也就是下圖所示的結構。  這就是我們庫當中，屬於框架的部分。 OK，我們最後再回顧一下，什麼是框架: > 框架：提供一個架構（檔案結構、約定等等），你必須遵守它，只要你遵守，那剩下的就全部處理通用需求了。 從這一點去考慮，我們的 MonoBehaviourSimplify 是不是框架呢？ 轉載請註明地址：涼鞋的筆記：[liangxiegame.com](http://liangxiegame.com) ## 更多內容 * QFramework 地址：[https://github.com/liangxiegame/QFramework](https://github.com/liangxiegame/QFramework) * QQ 交流群：[623597263](http://shang.qq.com/wpa/qunwpa?idkey=706b8eef0fff3fe4be9ce27c8702ad7d8cc1bceabe3b7c0430ec9559b3a9ce66) * **Unity 進階小班**： * 主要訓練內容： * 框架搭建訓練（第一年） * 跟著案例學 Shader（第一年） * 副業的孵化（第二年、第三年） * 權益、授課形式等具體詳情請檢視[《小班產品手冊》](https://liangxiegame.com/master/intro)：https://liangxiegame.com/master/intro * 關注公眾號：liangxiegame 獲取第一時間更新通知及更多的免費內容。