讓介面容易被正確使用，不易被誤用——effective c++學習筆記

 

讓介面容易被正確使用，不易被誤用（Make interface easy to use correctly and hard to use
incorrectly.）

 

如果客戶企圖使用某個介面而卻沒有獲得他所預期的行為，這個代碼不應該通過編譯；如果代碼通過了編譯，它的作為就是客戶想要的。

這一條準則非常重要，就像我自己定義的一個記憶體回收機制，它有兩個前提：

1、 
返回的對象的reference不允許進行delete操作。這個我是通過將解構函式設定為private函數來實現的。

2、 
函數返回後，這個reference不允許再被使用。這個目前沒有限定。這個通過什麼來限定？這裡可以考慮使用智能指標。

 

許多用戶端的錯誤可以因為引入新的類型而獲得預防。

樣本：

class Date

{

    public :

        Date(int month, int day, int year);

};

這個介面有一個問題，使用者調用建構函式是可能會傳入錯誤的參數，比如：Date(30, 3, 1982);，應該是3，30。

註：c++中建構函式失敗的通知方式有兩種：一是通過異常，一是通過狀態位。

可以定義一個結構體：

struct Day

{

    explicit Day(int d)

    : val(d){}

    int val;

};

進一步，month要能夠反映一年有12個月這個事實。

class Month

{

    public :

        static Month Jan(){return Month(1);}

 

    private:

        explicit Month (int m);//防止通過其他途徑產生Month

};

這樣，Date可以這樣調用：

Date(Month::Jan(), );

預防客戶錯誤的另一個方法是，限制類型內什麼事可做，什麼事不能做。常見的是加const。

“另types容易被使用，不易被誤用的表現形式”：除非有好理由，否則應該盡量令你的types的行為與內建的types一致。

一致性的介面更容易導致介面容易被使用。

任何介面如果要求客戶必須記得做某些事情，就是有這不正確使用的傾向。

比如，如果一個介面返回一個資源，而要求這個資源必須被客戶釋放，則可能發生兩個錯誤：未釋放和多重釋放。

可以使用智能指標消除資源泄漏的問題。

另外，tr1::shared_ptr有一個特性，就是他可以指定這個資源指標的刪除器。這樣就可以避免另外一個問題：“cross-DLL problem ”，這個問題發生於對象在動態連結程式庫中被new，而在另外一個DLL種被delete，這在很多平台上會導致運行期錯誤。

注意：

1、 
好的介面很容易被正確使用，不容易被誤用。你應該在所有的介面中努力達成這些性質。

2、 
“促進正確使用”的辦法包括介面的一致性，以及與內建類型的行為相容。

3、 
阻止誤用的辦法包括建立新類型，限制類型上的動作，束縛對象值，以及消除客戶對資源的管理責任。

4、 
tr1::shared_ptr支援定製型刪除器，這可防範DLL問題。可被用來自動解除互斥鎖。