首先要聲明一下，Fir0918服務端方面個人感覺實在是渣 代碼各種亂入，寫此博客只是記錄自己學習的點滴。並不是來告訴大家fir的代碼有多好。
TBaseObject 只有四個成員 對象所在地圖的X,Y以及對象類型objType(玩家 英雄 NPC 事件 等等)。以及對象創建的時間使用GetTickCount。成員函數也只有一個構造函數。
TActorObject: TActorObject .從代碼上看來是作爲Actor超類 。但是此類內部實際耦合了太多Player的成員 比如 Socket 句柄 ，衣服樣子 以及所屬行會等等。而從結構上來看
TActorObject 只是作爲一個抽象類來泛化人物 怪物 以及NPC的 具體功能。而此類卻耦合太多的人物操作。所以這裏並沒有設計好。需要解耦。關於屬性問題：其內部有三個關於屬性的結構體成員：
{人物屬性}
m_Abil: TAbility; //人物臨時屬性。此結構體用來計算人物所在等級應具有的基本屬性。之後再計算入m_wAbil內
m_WAbil: TAbility; //人物主要屬性。此結構體是人物的主要屬性值記錄。攻擊傷害是以此結構體作爲數據來計算。
m_AddAbil: TAddAbility;//人物附加屬性。此結構體 類似與TAbilty 。有不少重複的字段是一樣的。其作用是計算人物身上穿戴裝備的屬性值。然後和m_Abil相加 賦值給 m_wAbil 。
TAnimalObject : 此類實現了Actor的搜尋 和攻擊 以及 隨機的走動方法。以及處理Socket消息的小實現。個人認爲 此類功能應該在TActorObject內實現。再此多一層繼承關係是沒必要的。
TMonster : 此類作爲怪物類的基類 實現了攻擊目標 和基本邏輯處理(Run函數) 子類怪物繼承自其要實現新的功能基本 是在Run內進行重寫。
TAIObject : 此類 實現了自動控制的一些功能 但並未完全實現。從設計角度來看 此類是爲英雄以及假人實現做抽象的。但是個人認爲此類應該繼承自TPlayObject 而不是讓TPlayObject 繼承自TAIObject 畢竟 玩家是不需要自動控制的吧。或許需要掛機的功能?
TNormalNPC: 此類實現了各種腳本功能的支持 #IF #ACT 條件的支持！其實有點不太理解 爲什麼此類需要從TAnimalObject繼承。 而衛士類TSuperGuard繼承自TNormalNpc 卻只實現了攻擊玩家這種方法。對於TNormalNPC實現的腳本功能衛士是使用不上的。
TAIPlayObject : 假人的實現。
THeroObject : 英雄的實現。
思考分析：從繼承關係上來看TAnimalObject 不應該出現 此類應該集合在Actor類內。而TSuperGuard 也不應繼承自TNormalNPC。 而且FIR的源代碼內 Actor 也包含了TPlayObject 和 THeroObject的代碼：從繼承關係上來 應該從更新整理爲以下關係
如果非得在服務端實現 人物的掛機功能。那麼可以提取出一個公共接口。讓假人 和玩家 ，英雄 各自實現 其智能化的功能。