假设你正在操作一个Rectangle类。每个矩形可以通过左上角的点和右下角的点来表示。为了保证一个Rectangle对象尽可能小，你可能决定不把定义矩形范围的点存储在Rectangle类中，而是把它放入一个辅助结构体中，Rectangle中声明一个指向它的指针就可以了：
1 class Point { // class for representing points 2 3 public: 4 5 Point(int x, int y); 6 7 ... 8 9 void setX(int newVal); 10 11 void setY(int newVal); 12 13 ... 14 15 }; 16 17 18 19 struct RectData { // Point data for a Rectangle 20 21 Point ulhc; // ulhc = “ upper left-hand corner” 22 23 Point lrhc; // lrhc = “ lower right-hand corner” 24 25 }; 26 27 class Rectangle { 28 29 ... 30 31 private: 32 33 std::tr1::shared_ptr<RectData> pData; // see Item 13 for info on 34 35 36 37 }; // tr1::shared_ptr
1. 由返回指向对象内部数据的引用所引发的两个问题
1.1 问题分析
因为Rectangle的客户需要能够获知一个矩形的范围，类因此提供了upperLeft和lowerRight函数。然而，Point是一个自定义的类型，所以你需要留意Item 20：对于用户自定义类型，按引用传递比按值传递更高效，这些函数返回了对底层Point对象的引用：
1 class Rectangle { 2 3 public: 4 5 ... 6 7 Point& upperLeft() const { return pData->ulhc; } 8 9 Point& lowerRight() const { return pData->lrhc; } 10 11 ... 12 13 };
这种设计可以编译通过，但却是错误的。事实上，它是自相矛盾的。一方面，upperLeft和lowerRight被声明成const成员函数，因为它们只用来为客户提供获知矩阵包含哪些点的方法，并没有让客户修改矩阵（Item 3）。另一方面，两个函数都返回指向私有内部数据的引用——而此引用能够被调用者用来修改内部数据！举个例子：
1 Point coord1(0, 0); 2 3 Point coord2(100, 100); 4 5 const Rectangle rec(coord1, coord2); 6 7 // rec is a const rectangle from 8 9 10 // (0, 0) to (100, 100) 11 rec.upperLeft().setX(50); // now rec goes from 12 // (50, 0) to (100, 100)!
注意upperLeft的调用者是如何利用返回的指向rec内部的Point数据成员的引用来修改这个成员的。但是rec是const变量。
我们能从中学到两点。首先，一个数据成员的封装性同以这个数据成员的引用作为返回值的可访问级别最高（most accessible）的成员函数一致。在这种情况下，虽然ulhc和lrhc对于Rectangle来说是private的，它们实际上是public的，因为public函数upperLeft和lowerRight返回了指向它们的引用。第二，如果一个const成员函数返回指向数据的引用，而此数据被存储在当前对象之外，那么函数的调用者就能够修改这些数据。（这是bitwise constness局限性的附带结果 Item 3）。
1.2 句柄(handles)不仅包含引用，也包含指针和迭代器
我们讨论的都是返回引用的成员函数，但是如果它们返回指针或者迭代器，同样原因导致的同样问题也将会存在。引用，指针和迭代器都是句柄（handles），返回一个指向对象内部数据的句柄常常有破坏封装型的风险。也会导致从const成员函数传递出去的对象的状态被修改掉。
1.3 内部数据(internals data)不仅包含数据成员，也包括成员函数
我们通常认为一个对象的“内部数据”只针对数据成员，但非public的成员函数也是对象内部数据的一部分。因此，禁止返回指向它们的句柄同样重要。这意味着绝不要从成员函数中返回一个指向更低访问级别的函数的指针。如果你这么做了，有效的访问级别就是访问级别更高的那个函数，因为客户可以获得访问级别更低的函数的指针，然后通过指针来调用此函数。
2. 解决上面两问题的方法，为引用添加const
返回指向成员函数指针的函数并不普通，让我们重新关注Rectangle类和它的upperLeft和lowerRight成员函数。我们发现的两个问题可以通过简单的为其返回值添加const来消除：
1 class Rectangle { 2 public: 3 ... 4 const Point& upperLeft() const { return pData->ulhc; } 5 const Point& lowerRight() const { return pData->lrhc; } 6 ... 7 };
使用这个修改后的设计，客户可以读取定义一个矩形的点，但是不能修改它们。这意味着upperLeft和lowerRight的声明不再是一个谎言，因为它们不再允许调用者修改对象的状态。对于封装问题，我们的意图是让客户能够看到组成矩形的点，因此我们故意放松了封装型。更加重要的是，这是有局限性的“放松“：这些函数是只读的。
3. 返回const引用会引入新的问题
即便如此，upperLeft和lowerRight仍然返回了指向对象内部数据的句柄，这可能会在其它方面出现问题。特别是它能导致悬挂指针：指向部分对象的句柄不再存在。这种对象消失问题的最常见的根源在于按值返回的函数。举个例子，考虑一个为GUI对象返回边界框的函数，边界框用矩阵表示：
1 class GUIObject { ... }; 2 3 const Rectangle // returns a rectangle by 4 5 boundingBox(const GUIObject& obj); // value; see Item 3 for why 6 7 8 // return type is const
现在考虑一个客户如果使用这个函数：
1 GUIObject *pgo; // make pgo point to 2 ... // some GUIObject 3 const Point *pUpperLeft = // get a ptr to the upper 4 &(boundingBox(*pgo).upperLeft()); // left point of its 5 // bounding box
这个对boundingBox的调用将返回一个新的临时Rectangle对象.这个对象没有名字，我们叫它temp。upperLeft将在temp上被调用，这个调用返回了指向temp内部数据的引用，temp内部数据就是组成矩形的一个Point。pUpperLeft将会指向这个Ponit对象。到现在为止一切正常，但是还没完呢，因为在声明结束时，boundingBox的返回值——temp——将会被销毁，这将间接导致temp的Point对象被析构。这样使得pUpperLeft指向一个不再存在的对象；pUpperLeft在创建它的语句结束时变成了悬挂指针！
这也是为什么任何返回指向对象内部数据的句柄的函数都是危险的。不论这个句柄是一个指针，或者一个函数，或者一个迭代器。也不管这个函数有没有被声明为const。也不管成员函数返回的句柄是否为const。问题的关键在于函数有没有返回句柄，因为一旦返回了，就会有句柄比其指向的对象存在时间更长的危险。
4. 例外的情况
这并不意味着你永远不应该让一个成员函数返回一个句柄。有时候你必须这么做。举个例子，operator[]允许你从string或者vector中将单个元素摘出来，这些operator[]返回的就是指向容器内部数据的引用（Item 3）——容器被销毁的时候，它里面的数据也被销毁。但这样的函数只是一个例外。
5. 总结
避免返回指向对象内部数据的句柄（引用，指针或者迭代器）。不返回句柄可以增强封装性，帮助const成员函数的行为为真正的const，减少悬挂指针被创建的可能。