EC筆記：第4局部：18、接口正確運用，不易被誤用

EC筆記：第4局部：18、接口正確運用，不易被誤用。本站提示廣大學習愛好者：（EC筆記：第4局部：18、接口正確運用，不易被誤用）文章只能為提供參考，不一定能成為您想要的結果。以下是EC筆記：第4局部：18、接口正確運用，不易被誤用正文

• 好的接口容易被正確運用，不易被誤用

思索以下函數：

void func(int year,int month,int day){

//一些操作

}

這個函數看似合理，由於參數的名字曾經暴露了它的用處。但是假如只要寒暑簽名呢？如下：

void func(int,int,int);

就算我通知你，此處需求日期作為參數，你能夠會以月日年、日月年等不同方式作為參數。

正確的做法是把年月日都各自籠統為一個類（或許說是構造體）：

struct Year {

int year;

};

struct Month {

int month;

};

struct Day {

int day;

};

void func(Year year,Month month,Day day){

//一些操作

}

這樣即便你只要函數簽名，也不會隨便出錯。

• 用於內置類型的行為兼容

盡量要外行為上與現有類型兼容，由於普通用戶會先與類型作為參考。

如：int類型不支持：

int a=5;

int b=6;

int c=50;

a+b=c;//錯誤

那麼你自己定義的類型，也不應該有相似的語法：

MyType a;

MyType b;

MyType c;

a+b=c;//盡量不要這樣去做，除非你有更好的理由

• 樹立新類型、限制類型上的操作、約束對象值、消弭客戶的資源管理責任

為了避免用戶犯錯，普通的方式就是為我們的新類型加上各種限制，比方限定月份的值為1到12，日期的值為1到31等。在用戶輸出合法的值的時分給出明白的提示或正告。

• 想象各種被使用的場景

我們要假定用戶各種能夠犯錯的場景，比方，在多線程環境中運用，假如不支持多線程，就應該明白的在文檔中輸入。或許是，用戶的合法輸出，合法調用，我們應該盡能夠地停止合法性檢驗。

盡能夠讓用戶在不改動現有運用習氣的狀況下，盡能夠的少出錯。