Clean Code 無瑕的程式碼 第6章 物件及資料結構
第六章主題是資料抽象化，作者講述結構化程式與物件導向程式的差別，還有德摩特爾法則（The Law of Demeter）。
資料抽象化
比較6-1 與6-2 ，6-3與6-4 可知具體與抽象寫法的差別，6-2與6-4有用到 interface
抽象化可以隱藏資料的細節，使用者在不知道實體運算，能夠操縱資料的本質。
6-1 具體的座標點
public class Point{
public double x;
public double y;
}
6-2 抽象的座標點
public interface Point{
double getX();
double getY();
void setCartesian(double x, double y);
double getR();
double getTheta();
void setPolar(double r, double theta);
}
6-3 具體化的交通工具類別
FuelTankCapacityInGallons(){
double getGallonsOfGasoline();
}
6-4 抽象化的交通工具類別
public interface Vehicle{
double getPercentFuelRemaining();
}
初次看一定覺得??????，參考這篇文章了解interface的好處，就能夠理解資料抽象化的好處。
關於interface的好處 ?
維基百科
抽象資料型別
實現於程式時，抽象資料型別只顯現出其介面，並將實作加以隱藏。使用者只需關心它的介面，而不是如何實作。未來可以改變實作的方式。
資料/物件的反對稱性
物件與資料之間是對立且互補。
物件將資料隱藏在抽象層，將函式暴露在外。
資料結構直接將資料暴露在外，沒有提供存取函數。
看懂6-5與6-6的範例，再假設遇到兩種情況就知道作者想表達的內容
6-5是「結構化程式設計」的寫法，資料結構與函數分開。
6-6是「物件導向」的寫法，每個物件有資料與函數，資料與函數在一起。
第一種情況是新增計算周長的函數
第二種情況是新增一個圖形
6-5與6-6的範例為了教學方便全部程式寫在一起，實際上有條理的程式都會每個class一的檔案。判斷程式寫得好不好關鍵在於有變化的時候，舊有程式會改動多少？
看懂程式之後可知
結構化程式設計有利新增函數，不利新增物件。
物件導向程式設計有利新增物件，不利新增函數。
德摩特爾法則（The Law of Demeter）
只和朋友說話，不與陌生人聊天。
一個類別C內的方法f，應該只能呼叫以下事項的方法
C
任何由f所產生的物件
任何當做參數傳遞給f的物件
C類別裡實體變數所持有的物件
讀者可再參考王洪亮先生的著作《我的程式碼會說話》4.2.6 德摩特爾法則
德摩特爾法則又叫最小知識原則，「一個物件對另一個物件內部了解越少越好」。
類別A可以訪問相關的朋友類別B，不可以透過類別B訪問類別B的朋友類別C。
德摩特爾法則的優點可以降低耦合性益於維護擴展，付出的代價是會增加許多中間類別。
火車事故
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
作者反對一長串相連的程式呼叫像火車事故。
混合體
作者建議不要寫成四不像，物件導向就完全物件導向，資料結構就完全資料結構。
隱藏結構
這部份看得不是很懂？感覺像是介紹要取得絕對路徑又符合德摩特爾法則（The Law of Demeter）的寫法。
資料傳輸物件 （Data Transfer Objects, DTO）
類別中只有公共變數沒有函數，常用於資料庫溝通將資料庫內的資料轉為應用程式的物件或解析socket傳來的訊息。
6-7的範例bean只是讓物件導向愛好者看了比較開心。
活動記錄
特殊的DTO卻有擁有save 與 find的方法，通常活動記錄是從資料庫表格或資料來源直接轉換而來。
總結
針對問題的特性決定採用結構化程式設計或是物件導向程式設計，動作行為常變化要採用結構化程式設計，資料型態常變化要採用物件導向程式設計。
