[轉]http://www.shnenglu.com/tiandejian/archive/2007/05/18/cp_18.html
第四章. 設計規劃與聲明方式
軟件設計方案是用來幫助規劃軟件功能的，通常，它在一開始是一系列優秀的思想，但最終都會被具體化，直至其成為可用于開發的一系列具體接口。之后，這些接口必須轉換為 C++ 的聲明。本章中，我們將解決“如何設計和聲明優秀的 C++ 接口”這一問題。我們以下面的建議開始（它可能是設計接口時要注意的最為重要的一點）：接口應該易于正確使用，而不宜被誤用。這引出了一系列更為具體的建議，其中我們將討論十分寬泛的議題，包括正確性、效率、封裝、可維護性、可擴展性，還有你需要遵循的慣例。
本章并不期望對于優秀接口設計的建議做到包羅萬象，取而代之的是精選出一部分最為重要的內容。各種錯誤和問題對于類 / 函數 / 模板的設計者來說是家常便飯，本章就是用來時刻警示你遠離這些常見的錯誤，并為你提供這些問題的解決方法。
第18條： 要讓接口易于正確使用，而不易被誤用
C++ 中到處充滿了接口。函數接口、類接口、模板接口，等等。每個接口都是實現客戶端程序員與你的代碼相交互的一種手段。假設你的客戶通情達理，他們的項目也十分優秀，他們便會十分看重你的接口是否易于正確使用。這是千真萬確的，如果他們誤用了你的接口中的任一個，那么你也難推其咎。在理想狀態下，如果客戶端程序員嘗試使用一個接口，但是沒有達到預期的效果，那么代碼則不應通過編譯。反之，如果代碼通過了編譯，那么則必須要符合客戶端程序員的需求。
開發中我們應做到讓接口更易于正確使用而不易被誤用，這需要你考慮到客戶端程序員會犯的各種錯誤。請參見下邊的示例，假設你正在編寫一個表示日期時間的類的構造函數：
class Date {
public:
Date(int month, int day, int year);
...
};
乍一看，這一接口設計得很合理（至少在美國很合理），但是當客戶端程序員面對這樣的接口時，很容易犯下兩種錯誤。第一，他們可能會使用錯誤的傳參順序：
Date d(30, 3, 1995); // 啊哦，應該是“ 3, 30 ”而不是“ 30, 3 ”
第二，他們可能會傳進一個無效的月份或日期：
Date d(3, 40, 1995); // 啊哦，應該是“ 3, 30 ”而不是 “3, 40”
（這一示例看上去有些愚蠢，但是不要忘了，在鍵盤上 4 和 3 是緊挨著的。這種“擦肩而過”的錯誤在現實中并不少見）
客戶端程序員犯下的許多錯誤是可以通過引入新類型來避免的。實際上，對于防止不合要求的代碼通過編譯，類型系統是你最得力的助手。在上述情況下，我們可以引入幾個簡單的“包裝類型”來區別日期、月份、和年分，然后再在 Date 的 構造函數中使用這些類型：
struct Day {
explicit Day(int d) : val(d) {}
int val;
};
struct Month {
explicit Month(int m) : val(m) {}
int val;
};
struct Year {
explicit Year(int y) : val(y) {}
int val;
};
class Date {
public:
Date(const Month& m, const Day& d, const Year& y);
...
};
Date d(30, 3, 1995); // 報錯！類型錯誤
Date d(Day(30), Month(3), Year(1995));// 報錯！類型錯誤
Date d(Month(3), Day(30), Year(1995));// OK ，類型正確
我們可以改善上邊簡單的應用結構體的思路，讓 Day 、 Month 、 Year 變得“羽翼豐滿”，從而可以提供完善的數據封裝（參見第 22 條）。但是即使是結構體也足以說服我們：引入新的類型可以十分有效地防止接口誤用的發生。
只要你在恰當的地方使用了恰當的類型，你便可以合理地限制這些類型的值。比如說，一年有 12 個月，所以 Month 類型應該能夠反映出這一點。一個途徑是使用枚舉類型來表示月份，但是枚舉類型并不總能達到我們對于安全的需求。比如說，枚舉類型可以像 int 一樣使用（參見第 2 條）。一個更安全的解決方法是：預先定義好所有有效 Month 值 的集合：
class Month {
public:
static Month Jan() { return Month(1); } // 用來返回所有有效月份值
static Month Feb() { return Month(2); } // 的函數；
... // 下面你將看出為什么使用
static Month Dec() { return Month(12); } // 函數，而不是對象
... // 其他成員函數
private:
explicit Month(int m); // 防止創建新的月份值
... // 與月份相關的數據
};
Date d(Month::Mar(), Day(30), Year(1995));
如果上面代碼中使用函數來代替具體月份的思路讓你感到奇怪，那么可能是由于你已經忘記了聲明非局部靜態對象可能會帶來可靠性問題。第 4 條可以喚醒你的記憶。
為防止客戶端程序員犯下類似的錯誤，我們還可以采用另一個途徑，那就是嚴格限制一個類型可以做的事情。加強限制的一個常用的手段就是添加 const 。比如說，第 3 條中曾解釋過，對于用戶自定義類型 operator* 的返回值來說，具備怎樣程度的 const 特性就可以防止客戶端程序員犯下下面的錯誤：
if (a * b = c) ... // 啊哦，本來是想進行一次比較！
實際上，這僅僅是“讓接口易于正確使用，而不易被誤用”的另一種一般的做法：除非有更好的理由阻止你這樣做，否則你應該保證你創建的類型的行為與內建數據類型保持一致。客戶端程序員已經清楚 int 的行為，所以只要是合情合理，你就應該力求使你的類擁有與 int 一致的行為。比如說，如 果 a 和 b 是 int 類型，那么為 a*b 賦 值就是不合法的。所以除非你有好的理由拒絕這一規定，否則你自己創建的類型也應該將這一行為界定為不合法。當你舉棋不定時，就讓你的類型做與 int 一樣的事情。
設計接口時應防止與內建數據類型發生不必要的不兼容性，這樣做的真正目的是讓各類接口擁有一致的行為。除了一致性，很少有特征可以讓接口更加易于正確使用，同時，除了不一致性，也很少有特征可以讓接口變得更加糟糕。 STL 容器的接口大體上（但并不完美）是一致的，這就使得它們更易于使用。比如說每個 STL 容器都有一個名為 size 成員函數，它可以告訴我們這一容器中容納了多少對象。這一點與 Java 和 .NET 是不同的， Java 中使用 length 屬性 來表示數組的長度， length 方法 來表示字符串的長度，以及 size 方法來表示 List 的大小。而 .NET 中的 Array 擁有一個叫做 Length 的屬性，而 ArrayList 中功能相類似的屬性則叫做 Count 。一些開發人員認為，集成開發環境（ IDE ）的存在讓這類不一致性問題變得不那么重要，但是實際上他們大錯特錯了。不一致性問題會會給開發人員帶來無窮盡的煩惱，而 IDE 是絕不能解決這些問題的。
任何接口都需要客戶端程序員記憶一些易發生錯誤的內容，這是因為客戶端程序員可能會把這些東西搞砸。比如說，第 13 條中曾引入一個工廠函數來返回一個指向 Investment 層中動態分配對象的指針：
Investment* createInvestment();// 來自第 13 章，為簡化代碼省略參數表
為防止資源泄漏，由 createInvestment 返回的指針在最后必須被刪除，但是這將會給客戶端程序員留下至少兩個犯錯誤的機會：忘記刪除指針、多于一次刪除統一指針。
第 13 條中介紹了客戶端程序員如何將 createInvestment 的返回值保存在諸如 auto_ptr 或 tr1::shared_ptr 這樣的智能指針中，然后讓智能指針擔負起調用 delete 的責任。但是如果客戶端程序員忘記了使用智能指針，這該怎么辦呢？通常情況下，更好的接口的設計方案是：讓工廠函數返回一個智能指針，在一開始就不給問題任何發生的機會。
std::tr1::shared_ptr<Investment> createInvestment();
這樣便可以從根本上強制客戶端程序員將返回值存儲在一個 tr1::shared_ptr 中，在一個原始 Invesement 對象再有用之后，這樣做可以防止你忘記刪除這一無用的對象。
事實上，返回 tr1::shared_ptr 讓接口設計人員能夠防止由資源釋放所造成的客戶端錯誤，這是因為 tr1::shared_ptr 允許在智能指針創建時，將資源釋放函數（一個“刪除器”）綁定在這一智能指針中，而 auto_ptr 沒有這一功能。（參見第 14 條）
假設一個客戶端程序員從一個 createInvestment 中得到了一個 Investment* 指針，他可能會將這個指針傳給一個名為 getRidOfInvestment 的函數，而不是將其刪除。這樣的接口將會為客戶端程序員帶來新的錯誤，客戶端程序員將會使用錯誤的資源析構機制（也就是使用了 delete 而不是 getRidOfInvestment ）。實現 createInvestment 的程序員可以通過返回一個綁定了 getRidOfInvestment “刪除器”的 tr1::shared_ptr 來預防此類錯誤。
tr1::shared_ptr 提供了一個擁有兩個參數的構造函數：需要管理的指針，以及當引用計數值為零時需要調用的刪除器。關于創建綁定 getRidOfInvestment “刪除器”的 tr1::shared_ptr ，請看下面的方法：
std::tr1::shared_ptr<Investment> pInv(0, getRidOfInvestment);
// 嘗試創建一個 null 的 shared_ptr ，
// 并且讓其包含一個自定義的刪除器；
// 這樣的代碼無法通過編譯
這并不是合法的 C++ 語法。 tr1::shared_ptr 的構造函數的第一個參數必須是一個指針，而 0 則不是，它是一個 int 值。的確，它可以轉換成一個指針，但是這種情況下此類轉換并不值得推薦， tr1::shared_ptr 的第一個參數必須是一個實際的指針。通過一次轉型可以解決這一問題：
std::tr1::shared_ptr<Investment>
pInv(static_cast<Investment*>(0), getRidOfInvestment);
// 創建一個 null 的 shared_ptr ，
// 并且讓其包含一個自定義的刪除器；
// static_cast 的更多信息參見第 27 條
上面的代碼意味著，在實現 createInvestment 時，可讓其返回一個“綁定了 getRidOfInvestment 刪除器的 tr1::shared_ptr ”：
std::tr1::shared_ptr<Investment> createInvestment()
{
std::tr1::shared_ptr<Investment>
retVal(static_cast<Investment*>(0), getRidOfInvestment);
retVal = ... ; // 讓 retVal 指向恰當的對象
return retVal;
}
當然，如果在創建 pInv 之前就確定了其所管理的裸指針，那么將裸指針傳遞給 pInv 的構造函數更理想些，而不應該將 pInv 初始化為空值然后對其賦值。為什么這樣？請參見第 26 條。
使用 tr1::shared_ptr 的另一個較為顯著的好處在于：它自動為每個指針預留一個刪除器，用它們來排除另一類客戶端錯誤，也就是所謂的“跨 DLL 問題”。這一問題在下面的情況中會發生：一個動態鏈接庫（ DLL ）中使用 new 創建了一個對象，而這個對象在另一個 DLL 中由 delete 語句刪除了。在許多平臺上，此類跨 DLL 的“ new/delete 對”將導致運行時錯誤。 tr1::shared_ptr 可以防止此類問題發生，因為如果創建了一個 tr1::shared_ptr ，它的默認刪除器在同一個 DLL 中使用 delete 。舉例說，這將意味著如果 Stock 繼承自 Investment ，同時 createInvestment 是這樣實現的：
std::tr1::shared_ptr<Investment> createInvestment()
{
return std::tr1::shared_ptr<Investment>(new Stock);
}
那么返回的 tr1::shared_ptr 將在各 DLL 文件中自由穿梭，而不用考慮跨 DLL 問題。這一指向 Stock 的 tr1::shared_ptr 會始終追蹤這一事件：當 Stock 的引用計數值為零時，需要使用哪一個 DLL 的 delete 語句。
本條目講解的主要內容是如何讓接口更加易于正確使用，而不易被誤用，而不是 tr1::shared_ptr ，但是 tr1::shared_ptr 對于避免此類客戶端錯誤卻是一個不可多得的好工具，使用它是值得的。 tr1::shared_ptr 最為通用的實現來自 Boost （參見第 55 條）。 Boost 中的 shared_ptr 有兩個裸指針那么大，它為記錄和刪除專用數據使用動態分配內存，當調用函數的刪除器時使用虛函數，如果它認為一個應用程序是多線程的，那么當修改該程序的一個引用計數值時，將引入線程同步的開銷。（你也可以通過定義一個預處理記號來禁用多線程。） Boost 中的 shared_ptr 也是有缺點的：它比裸指針更大，更慢，而且使用輔助的動態內存。在許多應用程序中，這些額外的運行時開銷并不那么顯著，但是它可以降低客戶端程序員出錯的可能，這一點對每個人來說都是十分顯著的。
牢記在心
l 優秀的接口應該易于正確使用，而不易誤用。對所有的接口都應該力爭做到這一點。
l 保持與內置數據類型有一致的行為，是使接口易于正確使用的一種可行的方法
l 防止錯誤發生的方法有：創建新的數據類型，嚴格限定類型的操作，約束對象的值，不要將管理資源的任務留給客戶端程序員。