C++中到處充滿了接口。函數(shù)接口、類接口、模板接口，等等。每個接口都是實現(xiàn)客戶與你的代碼相交互的一種手段。假設(shè)你的客戶都是完全理性的，他們致力于更優(yōu)秀的完成當(dāng)前項目，他們便會十分看重你的接口是否能夠正確使用。這樣一來，如果你的接口中的任意一個被他們誤用了，那么這個接口便成了這一錯誤的“罪魁禍?zhǔn)?#8221;。在理想狀態(tài)下，如果客戶嘗試使用一個接口，但是沒有達到預(yù)期的效果，那么代碼則不應(yīng)通過編譯。反之，如果代碼通過了編譯，則運行結(jié)果必須要符合客戶的需求。
開發(fā)中我們應(yīng)做到讓接口更易于正確使用而不易被誤用，這需要你考慮到客戶會犯的各種錯誤。請參見下邊的示例，假設(shè)你正在設(shè)計一個表示日期時間的類的構(gòu)造函數(shù)：
class Date {
public:
Date(int month, int day, int year);
...
};
乍一看，這一接口設(shè)計得很合理（至少在美國很合理），但是當(dāng)客戶面對這樣的接口時，很容易犯下兩種錯誤。第一，他們可能會使用錯誤的傳參順序：
Date d(30, 3, 1995); // 啊哦，應(yīng)該是“3, 30”而不是“30, 3”
第二，他們可能會傳進一個無效的月份或日期：
Date d(2, 30, 1995); // 啊哦，應(yīng)該是“3, 30”而不是“2, 30”
（這一示例看上去有些愚蠢，但是不要忘了，在鍵盤上2和3是緊挨著的。這種“擦肩而過”的錯誤在現(xiàn)實中并不少見）
客戶犯下的許多錯誤是可以通過引入新類型來避免的。實際上，對于防止不合要求的代碼通過編譯，類型系統(tǒng)是你最得力的助手。在上述情況下，我們可以引入幾個簡單的“包裝類型”來區(qū)分日期、月份、和年份，然后再在Date的構(gòu)造函數(shù)中使用這些類型：
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，類型正確
我們可以改善上邊應(yīng)用結(jié)構(gòu)體的簡單思路，讓Day、Month、Year變得“羽翼豐滿”，從而可以提供完善的數(shù)據(jù)封裝性（參見條目22）。但是即使是結(jié)構(gòu)體也足以說服我們：適時引入新的類型可以十分有效地防止接口誤用。
只要你在恰當(dāng)?shù)牡胤绞褂昧饲‘?dāng)?shù)念愋停惚憧梢院侠淼叵拗七@些類型的值。比如說，一年有12個月，所以Month類型應(yīng)該能夠反映出這一點。一個途徑是使用枚舉類型來表示月份，但是枚舉類型并不總能達到我們對于類型安全的需求。比如說，枚舉類型可以像int一樣使用（參見條目2）。一個更安全的解決方法是：預(yù)先定義好所有有效Month值的集合：
class Month {
public:
static Month Jan() { return Month(1); } // 用來返回所有有效月份值
static Month Feb() { return Month(2); } // 的函數(shù)；
... // 下面你將看出為什么使用
static Month Dec() { return Month(12); } // 函數(shù)，而不是對象
... // 其他成員函數(shù)
private:
explicit Month(int m); // 防止創(chuàng)建新的月份值
... // 與月份相關(guān)的數(shù)據(jù)
};
Date d(Month::Mar(), Day(30), Year(1995));
如果上面代碼中使用函數(shù)來代替具體月份的思路讓你感到奇怪，那么可能是由于你已經(jīng)忘記了聲明非局部靜態(tài)對象可能會帶來可靠性問題。條目4可以喚醒你的記憶。
為防止客戶犯下類似的錯誤，我們還可以采用另一個途徑，那就是嚴(yán)格限制一個類型可以做的事情。加強限制的一個常用的手段就是添加const屬性。比如說，條目3中曾解釋過，const是如何通過限定operator*的返回值，從而防止客戶對用戶定義類型犯下以下的錯誤的：
if (a * b = c) ... // 啊哦，本來是想進行一次比較！
實際上，這僅僅是針對“讓接口易于正確使用，而不易被誤用”另一條一般性建議的一個表現(xiàn)形式，這條建議是：除非有更好的理由阻止你這樣做，否則你應(yīng)該保證你所創(chuàng)建類型的行為與內(nèi)建數(shù)據(jù)類型保持一致。因為客戶已經(jīng)清楚int的行為，所以只要是合情合理，你就應(yīng)該力求使你的類擁有與int一致的行為。比如說，如果a和b是int類型，那么為a*b賦值就是不合法的。所以除非你有好的理由拒絕這一規(guī)定，否則你自己創(chuàng)建的類型也應(yīng)該將這一行為界定為不合法。當(dāng)你舉棋不定時，就讓你的類型的行為與int保持一致。
設(shè)計接口時應(yīng)避免與內(nèi)建數(shù)據(jù)類型之間存在不必要的不兼容問題，這樣做的真正目的是保持各類接口行為的一致性。很少有特征能像一致性這樣，可以讓接口如此易于正確使用；同時，也很少有特征能像不一致性那樣，可以讓接口變得那般糟糕。STL容器的接口大體上（但并不完美）是一致的，這就使得它們更易于使用。比如說每個STL容器都有一個名為size成員函數(shù)，它可以告訴我們當(dāng)前這一容器中容納了多少對象。這一點與Java和.NET是不同的，Java中使用length屬性來表示數(shù)組的長度，length方法來表示字符串的長度，以及size方法來表示List的大小。而.NET中的Array擁有一個叫做Length的屬性，而ArrayList中功能相類似的屬性則叫做Count。一些開發(fā)人員認(rèn)為，集成開發(fā)環(huán)境（IDE）使得這類不一致性問題變得不那么重要，但是實際上他們想錯了。不一致性問題會給開發(fā)人員帶來無窮盡的煩惱，沒有哪個IDE是能夠完美解決這些問題的。
任何接口都需要客戶記憶一些易發(fā)生錯誤的內(nèi)容，這是因為客戶可能會把這些東西搞砸。比如說，條目13中曾引入一個工廠函數(shù)來返回一個指向Investment層中動態(tài)分配對象的指針：
Investment* createInvestment(); // 來自條目13，省略參數(shù)表以簡化代碼
為防止資源泄漏，由createInvestment返回的指針在最后必須被刪除，但是這將會給客戶留下至少兩個犯錯誤的機會：忘記刪除指針、多于一次刪除同一指針。
條目13中介紹了客戶如何將createInvestment的返回值保存在諸如auto_ptr或tr1::shared_ptr這樣的智能指針中，然后讓智能指針擔(dān)負起調(diào)用delete的責(zé)任。但是如果客戶忘記了使用智能指針，這該怎么辦呢？通常情況下，更好的接口的設(shè)計方案是：讓工廠函數(shù)返回一個智能指針，在一開始就不給問題任何發(fā)生的機會。
std::tr1::shared_ptr<Investment> createInvestment();
這樣便可以從根本上強制客戶使用tr1::shared_ptr來存儲返回值，這一做法基本上可以排除“忘記刪除當(dāng)前不再有用的Investment對象”的可能。
事實上，返回tr1::shared_ptr讓接口設(shè)計人員能夠防止與資源釋放相關(guān)的客戶端錯誤，這是因為在創(chuàng)建tr1::shared_ptr智能指針時，允許存在一個與當(dāng)前智能指針相綁定的資源釋放函數(shù)（即一個“刪除器”），而auto_ptr沒有這一功能。（參見條目14）
假設(shè)客戶從createInvestment中得到了一個Investment*指針，在進行刪除操作時，我們期望這一客戶將這個指針傳給一個名為getRidOfInvestment的函數(shù)，而不是使用delete。在這里，如果客戶會使用錯誤的資源析構(gòu)機制（也就是使用delete而不是getRidOfInvestment），那么這樣的接口就帶來了新的客戶端錯誤。實現(xiàn)createInvestment的程序員可以通過返回一個綁定getRidOfInvestment作為“刪除器”的tr1::shared_ptr來預(yù)防此類錯誤。
tr1::shared_ptr提供了一個擁有兩個參數(shù)的構(gòu)造函數(shù)，這兩個參數(shù)即：需要管理的指針，以及當(dāng)引用計數(shù)值為零時需要調(diào)用的刪除器。這使得我們可以創(chuàng)建使用getRidOfInvestment作為“刪除器”的空tr1::shared_ptr，請看下面的做法：
std::tr1::shared_ptr<Investment> pInv(0, getRidOfInvestment);
// 嘗試創(chuàng)建一個null的shared_ptr，
// 并且讓其包含一個自定義的刪除器；
// 這樣的代碼無法通過編譯
然而，這并不是合法的C++語法。tr1::shared_ptr的構(gòu)造函數(shù)的第一個參數(shù)必須是一個指針，而0則不是，它是一個int值。的確，數(shù)字可以當(dāng)做指針使用，但是這種情況下該做法并不值得推薦，tr1::shared_ptr的第一個參數(shù)必須是一個實際的指針。通過一次轉(zhuǎn)型可以解決這一問題：
std::tr1::shared_ptr<Investment>
pInv(static_cast<Investment*>(0), getRidOfInvestment);
// 創(chuàng)建一個null的shared_ptr，
// 并且讓其包含一個自定義的刪除器；
// static_cast的更多信息參見條目27
上面的代碼意味著，在實現(xiàn)createInvestment時，可讓其返回一個“綁定了getRidOfInvestment刪除器的tr1::shared_ptr”：
std::tr1::shared_ptr<Investment> createInvestment()
{
std::tr1::shared_ptr<Investment>
retVal(static_cast<Investment*>(0), getRidOfInvestment);
retVal = ... ; // 讓retVal指向恰當(dāng)?shù)膶ο?/span>
return retVal;
}
當(dāng)然，如果在創(chuàng)建pInv之前就確定了其所管理的原始指針，那么，比起“將pInv初始化為空值然后對其賦值”而言，“將原始指針傳遞給pInv的構(gòu)造函數(shù)”的方法更理想些。這是為什么呢？詳情請參見條目26。
tr1::shared_ptr可以自動為每個指針預(yù)留一個刪除器，它們可以排除另一類潛在的客戶端錯誤，即所謂的“跨DLL問題”，這是tr1::shared_ptr的一項尤為顯著的優(yōu)點。如果一個動態(tài)鏈接庫（DLL）中使用new創(chuàng)建了一個對象，而在另一個DLL中這個對象被delete語句刪除了，那么此時將會引發(fā)“跨DLL問題”。在許多平臺上，此類跨DLL的“new/delete對”將導(dǎo)致運行時錯誤。tr1::shared_ptr可以防止此類問題發(fā)生，因為如果創(chuàng)建了一個tr1::shared_ptr，它的默認(rèn)刪除器將在同一個DLL中使用delete。舉例說，如果Stock繼承自Investment，同時createInvestment是這樣實現(xiàn)的：
std::tr1::shared_ptr<Investment> createInvestment()
{
return std::tr1::shared_ptr<Investment>(new Stock);
}
那么返回的tr1::shared_ptr能夠在各DLL文件中自由穿梭，而不用考慮跨DLL問題。這一指向Stock的tr1::shared_ptr會始終追蹤這一事件：當(dāng)Stock的引用計數(shù)值為零時，需要使用哪一個DLL的delete語句來刪除它。
本條目講解的主要內(nèi)容是如何讓接口更加易于正確使用，而不易被誤用，而不是tr1::shared_ptr，但是tr1::shared_ptr對于避免此類客戶端錯誤卻是一個不可多得的好工具，學(xué)會使用它是值得的。tr1::shared_ptr最為通用的實現(xiàn)來自Boost（參見條目55）。Boost中的shared_ptr有兩個原始指針那么大，它在存儲計數(shù)信息和刪除器相關(guān)的數(shù)據(jù)時會使用動態(tài)分配的內(nèi)存，在進行刪除器調(diào)用時會使用虛函數(shù)，對于其識別為多線程的應(yīng)用程序，在修改引用計數(shù)時會引入線程同步的開銷。（你也可以通過定義一個預(yù)處理符號來禁用多線程。）簡言之：它比原始指針的體積更大，執(zhí)行速度更慢，并且使用輔助動態(tài)內(nèi)存。在許多應(yīng)用中，這些額外的運行時開銷是微不足道的，但是它可以顯著降低每個客戶出錯的可能，這一點絕對是振奮人心的。
時刻牢記
l 優(yōu)秀的接口應(yīng)該易于正確使用，而不易誤用。你應(yīng)該力爭讓你所有的接口都具備這一特征。
l 增加易用性的方法包括：讓接口保持一致性，讓代碼與內(nèi)建數(shù)據(jù)類型保持行為上的兼容性。
l 防止錯誤發(fā)生的方法包括：創(chuàng)建新的數(shù)據(jù)類型，嚴(yán)格限定類型的操作，約束對象的值，主動管理資源以消除客戶的資源管理職責(zé)。
l tr1::shared_ptr支持自定義的刪除功能。可以防止“跨DLL問題”，可以用于自動解開互斥鎖（參見條目14）。