欢迎光临散文网 会员登陆 & 注册

Clean Code 無瑕的程式碼 第6章 物件及資料結構

2021-06-16 23:16 作者:tkchenhaha  | 我要投稿

     第六章主題是資料抽象化,作者講述結構化程式與物件導向程式的差別,還有德摩特爾法則(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的方法,通常活動記錄是從資料庫表格或資料來源直接轉換而來。

總結

針對問題的特性決定採用結構化程式設計或是物件導向程式設計,動作行為常變化要採用結構化程式設計,資料型態常變化要採用物件導向程式設計。



Clean Code 無瑕的程式碼 第6章 物件及資料結構的评论 (共 条)

分享到微博请遵守国家法律