深入淺出SagaECO RPC篇(三) “解耦封包”

以下討論基於SagaECO svn 900版本
源代碼可以從這裡下載(約svn 400版本)

注意: 被分發SagaECO源代碼並不代表你被授權使用、修改、發布衍生的程式
換言之SagaECO團隊仍然保留一切權利(雖然SagaECO團隊早就消失了…

上文我們已經處理好輸出數據的格式和流程了，我們還有接收封包(Packet)的部分未解說呢。時間關係，讓我們一次過掀開完整的流程。

上一篇說的從Packet類的虛擬方法三巨頭

public virtual bool SizeIsOk 近乎沒有用到、忽略
public virtual Packet New()
public virtual void Parse(Client client)

一路追到最盡頭，發現使用了的是工廠模式。寫代碼的時候很可能還沒有出現lambda，加上工廠模式角色不明朗，先進行抽離不然很多人直接翻桌子(包括筆者)。

這下總算是釐清了抽象工廠的角色。

public virtual bool SizeIsOk
public virtual Packet New() 被lambda工廠搞到失業
public virtual void Parse(Client client)

最後剩神秘的Parse。先回到一個來自客戶端的封包類別看看。

作為區區一個DTO，居然還扮演著橋樑角色，作為底層物件被傳入高層物件這樣的的思想實在是太超前了XD。重點是，明明MapClient也有剛才的commandTable啊。最起碼，最起碼，該是這樣:

public virtual bool SizeIsOk
public virtual Packet New()
public virtual void Parse(Client client) 解耦完成，NetIO跟MapClient之間的事本來就沒有插手的餘地

解除束縛之後接收方的封包可以與上一篇的進度接軌了。

接收方和發送方不對稱乃正常現象，必然地我們要先取得ID才有之後的故事，所以 接收進來的封包天然地不用包括ID。至於應否在發送方封包那邊寫ID，其實也是沒有必要的(才不是偷懶稍後再動它)，最少IWritablePacket完全可以去掉ID這項。

這篇在止結束。下篇再見嚕~

後記: 竊以為SagaECO之所以面對嚴重技術負債問題，除了受早期語法等客觀限制之外，無論是早已離開團隊的核心開發者還是接手的維護者也好，未曾把代碼解讀過予他人。如果有這樣做的話，根基不會在不知不覺間歪了一個十年。
透過這裡寫的每一篇文章，解釋給他人的過程順道梳理了代碼，讓每一句代碼安詳地躺在它應該在的地方，詳和地微笑。多年後的我現在再次掀開這份古老的書本， 記憶昇華