假設(shè)你當(dāng)前設(shè)計的應(yīng)用程序里會涉及到矩形。每個矩形的區(qū)域都由它的左上角和右下角的坐標(biāo)來表示。為了讓Rectangle對象盡可能的小巧，你可能會做出這樣的決定：并不在Rectangle內(nèi)部保存這些點的坐標(biāo)信息，而是將這些信息保存在一個輔助結(jié)構(gòu)中，然后讓Rectangle指向它：
class Point { // 表示點的類
public:
Point(int x, int y);
...
void setX(int newVal);
void setY(int newVal);
...
};
struct RectData { // 供Rectangle類使用的點的數(shù)據(jù)
Point ulhc; // ulhc = "左上角"
Point lrhc; // lrhc = "右下角"
};
class Rectangle {
...
private:
std::tr1::shared_ptr<RectData> pData;
// 關(guān)于tr1::shared_ptr請參見條目13
};
因為Rectangle的客戶可能需要計算矩形的面積，所以這個類就應(yīng)該提供upperLeft和lowerRight函數(shù)。然而，Point卻是一個用戶自定義的類型，因此伴著你對條目20中相關(guān)推論的回憶——通過引用傳遞用戶自定義類型的對象要比直接傳值更高效，你會讓這些函數(shù)返回指向Point的引用：
class Rectangle {
public:
...
Point& upperLeft() const { return pData->ulhc; }
Point& lowerRight() const { return pData->lrhc; }
...
};
這樣的設(shè)計可以通過編譯，但是它卻是錯誤的。實際上，它是自我矛盾的。一方面，由于upperLeft和lowerRight的設(shè)計初衷僅僅是為客戶提供一個途徑來了解Rectangle的兩個頂點坐標(biāo)在哪里，而不是讓客戶去修改它，因此這兩個函數(shù)應(yīng)聲明為const成員函數(shù)。另一方面，這兩個函數(shù)都返回指向私有內(nèi)部數(shù)據(jù)的引用——通過這些引用，調(diào)用者可以任意修改內(nèi)部數(shù)據(jù)！請看下邊的示例：
Point coord1(0, 0);
Point coord2(100, 100);
const Rectangle rec(coord1, coord2); // rec是一個Rectangle常量
// 兩頂點是(0, 0), (100, 100)
rec.upperLeft().setX(50); // 但現(xiàn)在rec的兩頂點卻變?yōu)?/span>
// (50, 0), (100, 100)!
upperLeft返回了rec內(nèi)部的Point數(shù)據(jù)成員，在這里請注意：雖然rec本身應(yīng)該是const的，但是調(diào)用者竟可以使用upperLeft所返回的引用來修改這個數(shù)據(jù)成員！
上面的現(xiàn)象立刻引出了兩個議題：首先，數(shù)據(jù)成員僅僅與訪問限制最為寬泛的、返回該數(shù)據(jù)成員引用的函數(shù)擁有同等的封裝性。在這種情況下，即使ulhc和lrhc聲明為私有的，它們實際上仍然是公共的，這是因為公共函數(shù)upperLeft和lowerRight返回了指向它們的引用。其次，假設(shè)一個const成員函數(shù)返回一個引用，這一引用指向的數(shù)據(jù)與某個對象相關(guān)，但該數(shù)據(jù)卻保存在該對象以外，那么函數(shù)的調(diào)用者就可以修改這一數(shù)據(jù)。（這僅僅是按位恒定限制所留下的隱患之一——參見條目3。）
我們所做的一切都是圍繞著返回引用的成員函數(shù)展開的，但是如果成員函數(shù)返回的是指針或者迭代器，同樣的問題仍然會因為同樣的理由發(fā)生。引用、指針、迭代器都可以稱作“句柄”（獲取其它對象的渠道），返回一個指向?qū)ο髢?nèi)部部件的句柄，通常都會危及到對象的封裝性。就像我們看到的，即使成員函數(shù)是const的，返回對象的狀態(tài)也是可以任意更改的。
大體上講，對象的“內(nèi)部部件”主要是它的數(shù)據(jù)成員，但是非公有成員函數(shù)（也就是protected和private的）同樣也是對象的內(nèi)部部件。與數(shù)據(jù)成員相同，返回指向成員函數(shù)的句柄也是糟糕的設(shè)計。這意味著你不應(yīng)該讓一個公有成員函數(shù)A返回一個指向非公用成員函數(shù)B的指針。如果你這樣做了，B的訪問權(quán)層次就與A一樣了，這是因為客戶將能夠取得B的指針，然后通過這一指針來調(diào)用它。
所幸的是，返回指向成員函數(shù)指針的函數(shù)并不常見，所以我們還是把精力放在Rectangle類和它的upperLeft和lowerRight成員函數(shù)上。我們所發(fā)現(xiàn)的關(guān)于這些函數(shù)所存在的兩個問題都可以簡單的解決，只要將它們的返回值限定為const的就可以了：
class Rectangle {
public:
...
const Point& upperLeft() const { return pData->ulhc; }
const Point& lowerRight() const { return pData->lrhc; }
...
};
使用這一改進(jìn)的設(shè)計方案，客戶就可以讀取用來定義一個矩形的兩個頂點，但是他們不可以修改這兩個Point。這就意味著將upperLeft和lowerRight聲明為const并不是一個假象，因為它們將不允許調(diào)用者來修改對象的狀態(tài)。至于封裝問題，由于我們一直期望客戶能夠看到構(gòu)造一個Rectangle的兩個Point，所以這里我們故意放松了封裝的限制。更重要的是，這一放松是有限的：這些函數(shù)僅僅提供了讀的訪問權(quán)限。寫權(quán)限仍然是禁止的。
即使這樣，upperLeft和lowerRight仍然會返回指向?qū)ο髢?nèi)部部件的句柄，而且會存在其他形式的問題。在某些特定的情況下，會導(dǎo)致懸空句柄：即引用對象中不再存在的某些部分的句柄。能夠造成此類“會消失的對象”最普遍的東西就是函數(shù)返回值。舉例說，請考慮以下函數(shù)，它以一個長方形的形式返回一個GUI對象的邊界盒：
class GUIObject { ... };
const Rectangle boundingBox(const GUIObject& obj);
// 以傳值方式返回一個矩形。關(guān)于返回值為什么是const的，請參見條目3
現(xiàn)在請考慮一下客戶可能怎樣來使用這個函數(shù)：
GUIObject *pgo; // 讓pgo指向某個GUIObject
...
const Point *pUpperLeft = &(boundingBox(*pgo).upperLeft());
// 取得一個指向boundingBox左上角頂點的指針
調(diào)用boundingBox將會返回一個新的、臨時的Retangle對象。這個對象沒有名字，所以姑且叫它temp。隨后temp將調(diào)用upperLeft，然后此次調(diào)用將返回一個指向temp內(nèi)部部件的引用，特別地，指向構(gòu)造temp的一個點。pUpperleft將會指向這一Point對象。到目前為止一切都很完美，但是任務(wù)尚未完成，因為在這一語句的最后，boundingBox的返回值（即temp）將會被銷毀，這樣間接上會導(dǎo)致temp的Point被銷毀掉。于是，pUpperLeft將會指向一個并不存在的對象。這條語句創(chuàng)建了pUpperLeft，可也讓它成了懸空指針。
這就解釋了為什么說：任何返回指向?qū)ο髢?nèi)部部件句柄的函數(shù)都是危險的。至于句柄是指針還是引用還是迭代器，函數(shù)是否是const的，成員函數(shù)返回的句柄本身是不是const的，這一切都無關(guān)緊要。只有一點，那就是：只要返回了一個句柄，那么就意味著你正在承擔(dān)風(fēng)險：它可能會比它指向的對象存活更長的時間。
這并不意味著你永遠(yuǎn)也不能讓一個成員函數(shù)返回一個句柄。有些時候你不得不這樣做。比如說，operator[]允許你獲取string和vector中的任一元素，這些operator[]的工作就是通過返回容器內(nèi)部的數(shù)據(jù)來完成的（參見條目3）——當(dāng)容器本身被銷毀時，這些數(shù)據(jù)同時也會被銷毀。然而，這僅僅是一個例外，不是慣例。
時刻牢記
l 避免返回指向?qū)ο髢?nèi)部部件的句柄（引用、指針或迭代器）。這樣做可以增強(qiáng)封裝性，幫助const成員函數(shù)擁有更加恒定的行為，并且使懸空句柄出現(xiàn)的幾率降至最低。