物件及資料結構

物件及資料結構

結構化的程式碼(使用資料結構的程式碼)容易添加新的函式，而不需要變動已有的資料結構。

而物件導向的程式碼，容易添加新的類別，而不用變動已有的函式。

也可以反過來說:

結構化的程式碼難以添加新的資料結構，因為必須改變所有的函式。

物件導向的程式碼難以添加新的函式，因為必須改變所有的類別。

因此，使用物件導向感到困難的事物，在結構化裡卻比較容易。 使用結構化感到困難的事物，在物件導向卻比較容易。

讓每一件事物都是一個物件是一個神話。

某些時候，你真的只想使用簡單的資料結構，並透過結構式的程式碼來操作這些資料結構。

德摩特爾法則(The Law of Demeter)

模組不該知道關於它所操縱物件的內部運作。

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

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

例如以下的程式碼就違反了此法則。

String str = ctxt.getA().getB().getC();

(火車事故)

上面的程式碼串起來，像火車車廂一樣，所以通常被稱呼為火車事故(train wreck)。

比較好的做法應該是

A a = ctxt.getA();
B b = a.getB();
String str = b.getC();

至於這樣算不算是違反德摩特爾法則，要取決於他們是物件還是資料結構。 如果是物件，那應該被隱藏起來。 如果它們是資料結構，那本質上必然會揭露內部的結構，則德摩特爾法則在這種情況下並不適用。

(混合體)

半物件半資料結構，擁有函式也擁有公共變數、公共存取器、修改器。 這樣的混合體，會使程式難以添加新的函式，也難以添加新的資料結構。 代表作者不確定(甚至更糟 完全忽略)他們是否需要函式或形態的保護。

隱藏結構

根據要做的事情，去將整個事情包起來，隱藏在物件內部，僅僅取得需要的東西。 讓物件只做一件事情，而不去暴露太多內部資訊。

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

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

他們在將資料庫的原始資料轉換成應用程式內的物件時，往往擔任轉換過程的第一階段。

活動紀錄(Active Records)

活動紀錄是一種特殊的DTO，它們是擁有公用(或是可以讓bean存取的)變數的資料結構，但它們通常擁有save 與find 等方法。

不幸的是，有許多開發者會嘗試把這類的資料結構看做物件，然後加入處理商業法則(business rule)的方法。 這非常不洽當，因為會產生資料結構和物件的混合物。

比較好的解法，應該是另外建立一個包含商業法則的物件，用來隱藏內部資料(這些資料很可能就是活動紀錄的實體)的物件。

總結

物件會暴露行為，並隱藏內部資料。 ->不改變行為就輕易添加新類型物件，但現有物件很難增加新行為。

資料結構會暴露其資料，但不會有顯著行為。 ->很容易增加新行為，但很難在現有函式添加新的資料結構。

優秀的軟體開發者，應該根據需求，選擇適合的方法去完成手中工作。