說明在多人連線遊戲的情況下，內部資料要如何保護？最後講個屬性(property)的概念

今天跳下去寫扣，寫著寫著腦袋又開始打結了。於是暫停整理了一下自己的思緒。

原本玩家物件(Player)
成員：牌庫、手牌、棄牌
方法：出牌、抽牌、抽加棄牌

玩家狀態物件(PlayerStat)
成員：生命值、防護罩、牌庫、手牌
方法：扣血、治癒、建立護盾、扣護盾、封印、防禦、反震、空城、目眩(承受光芒)、抽掉卡片(混沌效果)、牌庫加牌(混沌效果)、展示手牌(光芒、混沌效果)

這時候開始發現玩家物件和玩家狀態物件功能越來越接近，所以打算把這兩個物件合併成一個。

另外因為玩家照理說不應該具備主動控制數值的方法(玩家幫自己加血)，所以任何可以改變玩家狀態的方法都應該被封裝為系統內部方法。那時候意識到玩家物件必須限制它可用的方法，於是就必須區分成以下：

• 給玩家使用的API介面
• 系統接收玩家API呼叫的介面
• 系統的API實作內容

然後又延伸一個問題：玩家不應該知道自己的牌庫內容。在思考相關問題的時候，意識到資料有三種層級：

• 公開資訊：場面狀態
• 個人資訊：玩家手牌內容、蓋牌內容
• 系統資訊：牌庫內容

然後因為遊戲是多人連線的形式，所以玩家這邊不會擁有遊戲的內部運作邏輯。於是思考資料拆分、介面&實作分離的方式要怎麼弄？因為程式寫一寫就會莫名其妙變成單機遊戲的思考方式，還好自己有想到這部份的問題

昨天有講到陣營共用資料的部份，這在四人對戰的時候一定會遇到，因為血量是按照陣營區分的。所以在底層實作中，血量訊息會被放在陣營層級的物件中被存取。這部分還沒想的很清楚，但大概在執行扣血的時候，會根據玩家ID轉換成對應的陣營ID，然後扣陣營的HP。老實說，想這部分有點頭痛

後面稍微復習了一下屬性property的概念，這是因為資料封裝而跑出來的概念
property表面上看起來很像是物件的成員，但是它其實是偽裝的函數呼叫

因為一般物件成員被封裝後，只能透過getter和setter去存取
原本的寫法：obj.x = obj.x+1
封裝後：obj.setXX(obj.getXXX()+1)
為了繼續保有原本存取成員的便利語法，同時又具備資料封裝的功能，property就被發明出來了。

實際語法就不貼了，看良葛格寫的說明文件吧。

以上為今天的進度，繼續加油吧!