我們花了 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
更多內容
-
QFramework 地址：https://github.com/liangxiegame/QFramework
-
QQ 交流群：623597263
-
Unity 進階小班：
- 主要訓練內容：
- 框架搭建訓練（第一年）
- 跟著案例學 Shader（第一年）
- 副業的孵化（第二年、第三年）
- 權益、授課形式等具體詳情請檢視《小班產品手冊》：https://liangxiegame.com/master/intro
- 主要訓練內容：
-
關注公眾號：liangxiegame 獲取第一時間更新通知及更多的免費內容。
