資料結構與物件的反對稱性:

• 物件: 將它們的資料在抽象層後方隱藏起來，然後將操縱這些資料的函式曝露在外。
• 資料結構 :將資料曝露在外，而且沒有提供有意義的函式。

它們是對立的且本質上是互補的:

• 物件導向的程式碼:難以添加新的函式，因為必須改變所有類別。
• 結構化的程式碼:難以添加新的資料結構，因為必須改變所有函式。

個人認為:

• 物件和物件導向適合為設計遊戲內Item類別使用。
• 結構化和資料結構適為設計角色、戰鬥等類別使用。

---

迪米特法則 ( The Law of Demeter )

一個類別 C 內的方法 f ，應該只能呼叫以下事項的方法

• C
• 任何由 f  所產生的物件
• 任何當作參數傳遞給 f 的物件
• C 類別裡實體變數所持有的變數

第四點的應用應是類似於後面所說的特殊的DTO若要有其他行為，應該要另外建立包含這些行為，隱藏內部資料(特殊DTO的實體)的物件。

方法不該呼叫『由任何函式所回傳之物件』的方法。

簡單解釋意思應該如下

f1(){
 return f2().getName();
}

f2(){
 return Object;
}

---

火車事故 (Train Wreck)

意思是一連串相連的程式呼叫，且是一種懶散的程式風格。
如下

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

解決的作法是將此類程式碼分割

Options opts = ctxt.getOptions();
File scratchDir = opts.getScratchDir();
final String outputDir  = scratchDir.getAbsolutePath();

而有沒有違反迪米特法則取決於所呼叫的程式是結構還是物件。

• 物件 : 其內部結構應該被隱藏起來，故違反。
• 無其他行為的結構 : 本質上必會揭露內部結構，所以迪米特法則在這情況下並不適用。

混合體

即半物件半資料結構，有函式做重要的事，也有公共變數或公共存取器、修改器。使得難以添加新的函式，也難以添加新的資料結構，是一種糊塗的設計，因為作者不確定，它是否需要函式或型態的保護。

如果 ctxt 是一個物件，應該要告訴它去做某某事情，不應該還被問到它的內部結構是什麼。

---

資料傳輸物件 (Data Transfer Objects, DTO)

最佳的資料結構是一種類別裡只有公用變數，沒有任何函式，這種資料結構被稱為資料傳輸物件或 DTO。
通常用在 :

• 和資料庫溝通
• 解析由 socket 傳來的訊息

往往用於「資料庫的原始資料」轉換成「應用程式內的物件」的第一階段。

活動紀錄 ( Active Records，特殊的 DTO)

擁有公共變數，卻也有sava、find 等用來瀏覽的方法。

---

總結

• 增加新資料型態的彈性: 採用物件導向。
• 增加新行為的彈性: 採用資料型態和結構化設計。

參考來源: Clean Code - A Handbook of Agile Software Craftsmanship  by Robert C. Martin