前幾天寫了《開源分享 Unity3d客戶端與C#分布式服務(wù)端游戲框架》，受到很多人關(guān)注，QQ群幾天就加了80多個人。開源這個框架的主要目的也是分享自己設(shè)計ET的一些想法，所以我準(zhǔn)備寫一系列的文章，介紹下自己的思路跟設(shè)計，每篇一個主題，這次介紹的是組件設(shè)計。
在代碼復(fù)用和組織數(shù)據(jù)方面，面向?qū)ο罂赡苁谴蠹业谝环磻?yīng)。面向?qū)ο笕筇匦岳^承，封裝，多態(tài)，在一定程度上能解決不少代碼復(fù)用，數(shù)據(jù)復(fù)用的問題。不過面向?qū)ο蟛皇侨f能的，它也有極大的缺陷：
一旦父類中增加或刪除某個字段，可能要影響到所有子類，影響到所有子類相關(guān)的邏輯。這顯得非常不靈活，在一套復(fù)雜的繼承體系中，往父類中改變字段會變得越來越麻煩，比方說ABC是D的子類，某天發(fā)現(xiàn)需要增加一個AB都有的數(shù)據(jù)，但是C沒有，那么這個數(shù)據(jù)肯定不好放到父類中，只能將AB抽象出來一個父類E，E繼承于D，AB共有的字段加到E中，一旦繼承結(jié)構(gòu)發(fā)生了變化，可能接口也要改變，比方說之前有個接口傳入?yún)?shù)類型是E，當(dāng)AB不再需要共用的那個字段，那么需要調(diào)整繼承關(guān)系，讓AB重新繼承D，那么這個接口的傳入?yún)?shù)類型需要改成D，其中的邏輯代碼很可能也要發(fā)生調(diào)整。更可怕的是游戲邏輯變化非常復(fù)雜，非常頻繁，可能今天加了個字段，明天又刪掉了，假如每次都要去調(diào)整繼承結(jié)構(gòu)，這簡直就是噩夢。繼承結(jié)構(gòu)面對頻繁的數(shù)據(jù)結(jié)構(gòu)調(diào)整感覺很無力。繼承結(jié)構(gòu)無法運行時增加刪除字段，比如玩家Player平常是走路，使用坐騎后就騎馬。問題是坐騎的相關(guān)信息就需要一直掛在Player對象上面。這就顯得很不靈活，我不騎馬的時候內(nèi)存中為啥要有馬的數(shù)據(jù)？接口也有同樣的問題，一個類實現(xiàn)了一個接口，那么這個接口就永遠粘在了這個類身上，你想甩掉她都不行，還是以騎馬為例，玩家Player可以進行騎行，那么可能繼承一個騎行的接口，問題是，當(dāng)我這個Player從坐騎上下來時，玩家Player身上還是有騎行的接口，根本沒法動態(tài)刪掉這個接口！可能例子舉得不是很對，但是道理表述的應(yīng)該很清楚了。使用面向?qū)ο罂赡軐?dǎo)致災(zāi)難性后果，游戲開發(fā)中有新人有老人，有技術(shù)好的，有技術(shù)差的。人都是喜歡偷懶的，當(dāng)你發(fā)現(xiàn)調(diào)整繼承關(guān)系麻煩的時候，有可能AB中增加一個字段為了省事直接就放到父類D中去了。導(dǎo)致C莫名奇妙的多了一個無用的字段。關(guān)鍵還沒法發(fā)現(xiàn)，最后導(dǎo)致父類D越來越大，到最后有可能干脆就不用ABC了，直接讓所有對象都變成D，方便嘛！是的，很多游戲就是這么干的，開發(fā)到最后根本就不管繼承關(guān)系了，因為想管也管不了了。
面向?qū)ο笤诿鎸?fù)雜的游戲邏輯時很無力，所以很多游戲開發(fā)者又倒退了回去，使用面向過程進行開發(fā)游戲，面向過程，簡單粗暴，不考慮復(fù)雜的繼承，不考慮抽象，不考慮多態(tài)，是開發(fā)屆的freestyle，挽起袖子就開擼，但同時，代碼邏輯的復(fù)用性，數(shù)據(jù)的復(fù)用性也大大降低。面向過程也不是一種好的游戲開發(fā)模式。
組件模式很好的解決了面向?qū)ο笠约懊嫦蜻^程的種種缺陷，在游戲客戶端中使用非常廣泛，Unity3d，虛幻4，等等都使用了組件模式。組件模式的特點：
1.高度模塊化，一個組件就是一份數(shù)據(jù)加一段邏輯
2.組件可熱插拔，需要就加上，不需要就刪除
3.類型之間依賴極少，任何類型增加或刪除組件不會影響到其它類型。
但是目前只有極少有服務(wù)端使用了組件的設(shè)計，守望先鋒服務(wù)端應(yīng)該是使用了組件的設(shè)計，守望先鋒的開發(fā)人員稱之為ECS架構(gòu)，其實就是組件模式的一個變種，E就是Entity，C就是Component，S是System，其實就是將組件Component的邏輯與數(shù)據(jù)剝離，邏輯部分叫System，話題扯遠了，還是回到ET框架來把。
ET框架使用了組件的設(shè)計。一切都是Entity和Component，任何類繼承于Entity都可以掛載組件，例如玩家類：
public sealed class Player : Entity{ public string Account { get; private set; } public long UnitId { get; set; } public void Awake(string account) { this.Account = account; } public override void Dispose() { if (this.Id == 0) { return; } base.Dispose(); }}給玩家對象掛載個移動組件MoveComponent，這樣玩家就可以移動了，給玩家掛上一個背包組件，玩家就可以管理物品了，給玩家掛上技能組件，那么玩家就可以施放技能了，加上Buff組件就可以管理buff了。
player.AddComponent<MoveComponent>();player.AddComponent<ItemsComponent>();player.AddComponent<SpellComponent>();player.AddComponent<BuffComponent>();組件是高度可以復(fù)用的，比如一個NPC，他也可以移動，給NPC也掛上MoveComponent就行了，有的NPC也可以施放技能，那么給它掛上SpellComponent，NPC不需要背包，那么就不用掛ItemsComponent了
ET框架模塊全部做成了組件的形式，一個進程也是由不同的組件拼接而成。比方說Loginserver需要對外連接也需要與服務(wù)器內(nèi)部進行連接，那么login server掛上
// 內(nèi)網(wǎng)網(wǎng)絡(luò)組件NetInnerComponent，處理對內(nèi)網(wǎng)連接Game.Scene.AddComponent<NetInnerComponent, string, int>(innerConfig.Host, innerConfig.Port);// 外網(wǎng)網(wǎng)絡(luò)組件NetOuterComponent，處理與客戶端連接Game.Scene.AddComponent<NetOuterComponent, string, int>(outerConfig.Host, outerConfig.Port);比如battle server就不需要對外網(wǎng)連接（外網(wǎng)消息由gateserver轉(zhuǎn)發(fā)），那么很自然的只需要掛載一個內(nèi)網(wǎng)組件即可。
類似Unity3d的組件，ET框架也提供了組件事件，例如Awake，Start，Update等。要給一個Component或者Entity加上這些事件，必須寫一個輔助類。比如NetInnerComponent組件需要Awake跟Update方法，那么添加一個這樣的類即可：
[ObjectEvent]public class NetInnerComponentEvent : ObjectEvent<NetInnerComponent>, IAwake, IUpdate{ public void Awake() { this.Get().Awake(); } public void Update() { this.Get().Update(); }}這樣，NetInnerComponent在AddComponent之后會調(diào)用其Awake方法，并且每幀調(diào)用Update方法。
ET沒有像Unity使用反射去實現(xiàn)這種功能，因為反射性能比較差，而且這樣實現(xiàn)的好處是這個類可以放到熱更dll中，這樣組件的Awake Start，Update方法以及其它方法都可以放到熱更層中。將Entity和Component做成沒有方法的類，方法都放到熱更層，方便熱更修復(fù)邏輯bug。
組件式開發(fā)最大的好處就是不管菜鳥還是高手，開發(fā)一個功能都能很快的知道怎么組織數(shù)據(jù)怎么組織邏輯?？梢酝耆艞壝嫦?qū)ο蟆Ｊ褂妹嫦驅(qū)ο箝_發(fā)最頭疼的就是我該繼承哪個類呢？之前做過最恐怖的就是虛幻三，虛幻三的繼承結(jié)構(gòu)非常多層，完全不知道自己需要從哪里開始繼承。最后可能導(dǎo)致一個非常小的功能，繼承了一個及其巨大的類，這在虛幻三開發(fā)中屢見不鮮。所以虛幻4改用了組件模式。組件模式的模塊隔離性非常好，技術(shù)菜鳥某個組件寫得非常差，也不會影響到其它模塊，大不了重寫這個組件就好了。
正是因為ET使用了可拆卸的組件模式，ET可以將所有服務(wù)器組件都裝到同一個進程上，那么這一個進程就可以當(dāng)作一組分布式服務(wù)器使用。從此用vs調(diào)試分布式服務(wù)器成為了可能。正因為這樣，平常開發(fā)只使用一個進程，發(fā)布的時候發(fā)布成多個進程就行了。說實在的，不是吹牛，這是一個偉大的發(fā)明，這一發(fā)明解決了分布式游戲服務(wù)器開發(fā)中的大大大難題，極大的提高了開發(fā)效率。
