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