【步兵 經驗篇】組件模式的特點 by EOS.
組件模式對u3d的開發者可能並不陌生，因爲其框架設計大量的使用了這種模式，
但是cocos卻沒有使用，不過後來出的js也開始套用這種模式，他能被效仿，自然有他的優勢，
接下來就總結一下，我對組件模式的一些瞭解。
高複用性
提到組件模式，我覺得他遵循了“組合”優於“繼承”的設計準則，接下來我們就舉個例子。
假設有現在有跑車、汽車和坦克，可能會有人這樣設計：
car <- 坦克
<- 裝甲車
<- 跑車跑車是不具備戰鬥功能的，如果把戰鬥功能寫在car中，可以實現，以後再加入潛水呢，入地呢？
無疑會導致冗餘繼承，而且可能會因爲自己所不具備的功能引發各種各樣的bug
所以這樣設計更合理些，car只保留基礎的功能。
car <- 戰鬥car <- 坦克
<- 裝甲車
<- 跑車如果又出現了潛水的車呢，可能會是這樣的。
car <- 潛水car <- 潛水車
<- 戰鬥car <- 坦克
<- 裝甲車
<- 跑車但是又出現了新的 戰鬥潛水坦克呢？當然可以寫一個潛水戰鬥car然後把相應的功能考過來。
但是這樣重複的東西，我們明明實現了，卻無法複用，無疑讓人格外的不爽。怎麼辦呢？
這時又要轉移仇恨，說爲什麼要出什麼戰鬥潛水車啊，有病啊！@#*!#@#￥，來發泄自己的情緒。
如果使用了組件模式，就可以很好的解決此類問題。組件模式中，car就一個變成了容器，
等着你來給他添加各種功能，想要什麼模塊，塞進去，他就可以是跑車、可以是坦克、也可以是潛水坦克。
運行時：即插即拔
比如現在有一個跑道，上邊有N個buff，觸碰後會加個閃光、加個幻影、變個造型、體積變小什麼的。
如果把這些所有的效果都寫到一個類中，然後openEffect(xxx)開啓種種效果的話，無疑這樣會導致你的類變的十分龐大。
而且加新需求，你就要繼續塞進你的類中，到最後會導致他變成一個龐然大物，難以維護。
而且如果有N個類繼承了它，無疑每次修改這個類都存在非常大的風險，通常我們不會去修改一個非常穩定的模塊，
因爲每次修改爲了保證它沒有問題，都需要進行大量的測試，與其相關甚至不相關的模塊，都要測試才能確定。
因爲你不能確定，它不會出現因爲數據的共享而引發的bug。就像開發過程中，永遠要備份一個的穩定版，
遇到查不出的bug或來不及補完的功能或其他緊急情況也能保證上線，穩定是必須的。
組件模式用組件模式也能得到很好的解決，可以給一個buff組件列表，
觸碰buff加進來，每個組件負責自己的邏輯，到時間再把自己移除掉。
低耦合性
理想的狀況是，我只負責自己的模塊，確保自己沒有問題後，只提供接口給你調用，那麼這個模塊就是穩定的。
但是實際開發中是不存在的，組件就是提供給使用者的，必然和使用者之間產生關聯性，也就是耦合性。
舉個反例，也就是高耦合。比如有一個流程A->B->C->D，最噁心的方案是A中引用B，B中引用C，C中引用D。
當B被取消時候，A又要重新引用C，BD調換順序時候，ABC都後改動，真是牽一髮而動全身。
如果最後再加個D反饋給A，那就更加不堪設想。~
但是我們明明就可以用一個很簡單的循環來處理，你就會說了誰會這麼傻，可能如此簡明的問題你不會。
但當問題被複雜話，又或者一開始只有A然後BCD是漸漸的加入的，很可能爲了意識方便，就那麼間的
用了一個“簡單的處理辦法”，漸漸的，就很可能就會被引導成前面所說的情況，正所謂“當局者迷”。
而組件模式能從根本上組織這種問題的發生，因爲它只負責自己的部分，不會引進組件到自身。
其實這也是功能模塊化，所具備的基本特點。
易測試性
合理劃分組件，可以讓組件相對功能單一，那麼相對複雜的功能出錯的概率會變小，測試它也將變得更簡單。
比如它和使用者只產生一些數據耦合，那麼只要使用者具備着這樣數據就可以使用，成爲組件使用者。
舉例：比如我們是爲一個坦克寫的一個移動組件，使用到了，他的座標(x,y,z)。
那麼我們完全可以使用一個具備(x,y,z)屬性的小球，來進行測試，不必去理會坦克其複雜的結構。
通過測試確定沒問題，那麼之後該模塊引發報錯的概率將很低。
功能越單一，出錯的概率也就越小，反推寫一個幾百行的函數，出錯的概率更大，
所以應該善於把函數簡單化、短小化，最好是一屏之內，閱讀起來也很舒服。
改動代價小
程序最恨的是什麼？或許就是”特殊處理“，往往給你一個需求，你想出很好的方案。
但當需求不斷變化的時候，由於經驗不足或者疏忽，沒有預留一些可拓展的接口，
你就需要做各種各樣的”特殊處理“，然後就這樣不停的破壞你的結構，你的流程，
原本清晰的分支、結構變成一丟亂麻，到最後可能自己都不想去看。
因爲組件有功能單一，耦合性低的特點，所以修改起來，對其他模塊影響很小。
可以較省心的做一些改動，另外之前也說過，我們是不願意去修改以穩定的東西的。
所以當需要改動太的太多或者之前有很多地方使用且很穩定，那麼我們可能就需要重新。
就算如此寫一個組件所花費的代價也遠遠小於重新寫一個具有相同功能的類或一套流程。
總結
組件模式其模塊化的特點，才頗受遊戲引擎的架構師們的喜愛，模塊間交集越少，越獨立，
相對所需的付出也就越少，也不需要一人包攬多個模塊，節省更多的精力在自己的模塊上。
遊戲需求的頻繁多變，相應功能的變化多端，以及與其相對於的快節奏開發，
或許正是組件模式開發，備受遊戲開發者們喜愛的原因=、=
(ps：推薦一首歌《一人我編程累》~ 嘖嘖，那個詞~穩得很！)
See Again~
之前
真愛無價，歡迎打賞~
