在上一篇呢，我們的得到了目前庫的一個分層圖，如下:
而這個圖中，把我們的庫分成兩個部分。一部分是架構，一部分是工具/庫。
架構部分，隻有一個 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 擷取第一時間更新通知及更多的免費内容。