在設計模式中有一個原則叫做合成復用。

在游戲編程領域中，常常需要讓一個對象實現(xiàn)熱插拔的功能。但是不能從代碼處進行熱插拔，因為這違反了開閉原則。

所以漸漸的基類的體量越來越大，形成了所謂的胖球。

當然我們也可以用裝飾者模式，來擴展對象的功能。

為什么要實現(xiàn)熱插拔，因為對于同樣的一個player實體，我們希望他有背包功能，也希望他有寵物功能。我們希望在特定的時候，禁止甚至沒有背包功能。

這個時候，就得掏出我們的組件模式了。

典型的組件模式就ECS。unity和ue的組件。

組件可以隨時隨地取消和掛載。

組件與組件之間完全可以獨立運行，但是通常有需要導致某個組件依賴于另一個組件

比如一個移動組件，往往依賴對象的transform組件

我們的技能組件也會依賴于數(shù)值組件。這種依賴是無法避免的。

我仿照著unity的組件，構(gòu)建了一個組件系統(tǒng)。

Entity和Component

entity只具備一個功能，保存Component的索引，并開放出組件的添加和獲得的接口。

Component的功能就更簡單的，如果不考慮生命周期，那么Component只需要持有entity的索引，以便獲得entity上掛載的其他Component來執(zhí)行來的邏輯即可。在子類中實現(xiàn)具體的邏輯。

ECS又怎么做呢？

將原有的Component拆分為Component和system。Component只具備數(shù)據(jù)，system只處理數(shù)據(jù)，這樣就可以把Component放在棧上去處理了。但是這需要特殊處理。目前我只能把Component放在堆上。

entity只具備一個id。在創(chuàng)建entity的時候，是通過entitymanager給與一個id。

entitymanager再通過這個ID來查詢對應的Component。

由于system和Component分離，因此system大量的使用了this的語法糖，從代碼側(cè)為為Component添加功能。每個Component都有一個對應的system。

從而讓ecs代碼，在調(diào)用上與以往一樣。只是代碼結(jié)構(gòu)有所變化

大功告成。沒有做數(shù)據(jù)整理的ecs框架。