組件的概念，只是在我們項目中的稱呼。至於其他人怎麼稱呼這種模式，我則不是很清楚。如果這個名字不對的話，請告訴，我在文檔中修復。免得影響其他人的認知。
其實我本無意寫這篇文章。因爲在項目中引入這個想法的人並不是我，所以我覺得整理其他人的想法，沒有任何意義。不過。組件的後期改動我有相當程度的參與，並且Update的更新模式是我進行修改的，並且我已經寫了一篇文章描述這個變化的過程，有人表示看不懂。所以，就補上一篇組件的說明。常規的設計
一般情況下，內容的設計會把一個對象的內容完全封裝到一個對象中（哈哈，當然如果是按照面向對象的方式來實現的）。讓我們來暢想一下一般情況下一個對象都會有什麼東西。位置的移動（基礎、移動、減速、加速等）、傷害邏輯（爆炸、碰撞傷害）、對其他內容的影響邏輯（擊退、斥力盾啥的）、位置的顯示、附屬組件的位置調整。一般情況下，這些功能會把公用部分放到合適的位置，比如說移動部分的代碼基本上所有的東西都會有，所以這部分內容會添加最基礎的組件比如說放置到最基礎層面的Objectbase。算了上個插圖。
爲了實現功能就需要將覈實的功能放到合適的位置去，比如說，位置移動的功能。基本上所有的對象都有，那麼基本上這個功能就需要放到ObjectBase中。攻擊範圍的概念基本上只有怪物纔會有，那麼這部分功能就需要放到怪物層級上。彈幕上的功能則相對比較複雜。普通彈幕很簡單，就是普通的東西。但是爆炸的彈幕則需要添加上爆炸的邏輯。追蹤的彈幕則需要添加上追蹤的邏輯。如果一個彈幕既有爆炸又有追蹤。那麼使用面向對象的方式來進行設計。這個地方就有兩個個選擇了，1 父類實現相關的內容，子類選擇性的使用。但是因爲子類的變動而影響到了父類，這違反了開閉原則對吧。或許，你覺得違反原則，這個並不重要。但是父類頻繁的變更，會給子類帶來莫名其妙的BUG這個時間長了，你就會有體會了。；2 子類實現自己的東西。如果選擇其中第二種方式。那麼相同的功能則需要抽離出來，想使用這塊功能的單獨使用這塊功能對吧但是這個違反了面向對象的思想對吧。
組件設計
好，既然面向對象解決這個問題存在困難。那麼我們就換個思路，就是剛纔我們剛纔提到的第二種解決方式。如果所有的功能我們都進行抽離出來，你想用的時候直接掛在上這部分功能。那麼，我們不使用繼承。也可以實現功能的複用。如果你覺得某一部分功能不夠用。完全可以做一個功能類似的組件替換掉原來的組件。封裝，將功能形成一個整體；繼承，繼承也可以看成子類使用父類的組件；多態，功能的替換，這不就是多態嗎。其實組件的設計或許跟繼承使用了不同的做法。但是基礎的封裝、繼承、多態。我們都可以提供。其實呢，這是另一種繼承。哈哈。有點意思。
組件的好處
可以更加完美的實現繼承的設計思想，只是這一點其實已經足夠吸引人了。其實我們最開始使用這種設計也正是基於這種想法。不過實現完了之後。我發現，其實因爲使用了組件，所以我們把一個實體拆分成了很多個小的組件。引用一下昨天的圖。
豎着看。這是一個個的實體。但是從側面看，那跟實體就沒什麼關係了。每一個組件都是一個單獨的個體。在這一幀中，只要所有的組件都調用了Update函數就OK了。那麼去調整組件Update更新順序也就可以實現了。讓相同類型的組件靠近更新這種想法也可以。至於組件的更新順序嘛。不要按照添加的順序嘛。可以給他們一個排序字段嘛。按照你設定的排序進行就可以。簡單的很。代碼我就不貼了。因爲可能有人看不懂。算了。