Effective C + +: Clause 28: Avoid returning handles point to internal members of an object

A

Sometimes in order to make an object as small as possible, you can put the data in another auxiliary struct, and then let a class to point to it. Look at the following code:

Class Point {public:point (int x, int y), void SetX (int newval), void sety (int newval);}; struct Rectdata {point ulhc; Point LRHC;}; Class Rectangle {public:point& Upperleft () const {return pdata->ulhc;} point& lowerright () const {return pdata->lrhc;} Private:std::tr1::shared_ptr<rcetdata> PData;};

This design looks very beautiful. But it is wrong, in fact it is self-contradictory, look at the following code:

Point Coord1 (0, 0); Point Coord2 (+), const Rectangle Rec (COORD1, coord2), Rec.upperleft (). SetX (50);

The reason for the error: (1) Upperleft () and Lowerright () These two functions are const, so the customer can not change the rectangle;

(2) Two functions return reference to the private internal data, and the caller can then change the internal data through these reference.

The caller of the Upperleft can use the returned reference to change the member. But Rec is actually supposed to be immutable (const)!

So the above kind of design is wrong!!!

So from this example, we can get the following lesson:

(1) The encapsulation of member variables is broken by reference.

(2) Assuming that the const member function is out of a reference, which refers to the data associated with the object itself, and it is stored outside the object, the caller of the function can alter the data.

In the same way, the reference, pointer, and iterator of the returned object will cause this situation, which are all "handles". Returns a handle that represents the internal data of the object, reducing the encapsulation of the object.

(ii) methods of settlement:

Simply adding a const to the return type of the two functions would be:

Class Rectangle {public:const point& upperleft () const {return pdata->ulhc;} Const point& Lowerright () const {return pdata->lrhc;} Private:std::tr1::shared_ptr<rcetdata> PData;};

With this change, customers can only read rectangular points, but they cannot scribble them.

Three

The above workaround ensures that the internal objects are not altered. But it may lead to dangling handles (empty hanging number card): Such a handles point of the object (belongs to) no longer exist.

The most common source of such "objects that no longer exists" is the function return value.

Class Guiobject {...}; Const Rectangle BoundingBox (const guiobject& obj); guiobject* pgo;const point* pupperleft = & (BoundingBox (*PGO). Upperleft ());

you will find (BoundingBox (*PGO). Upperleft ()) This is a point object. But when this sentence runs out, this temporary object temp will be refactored. At this point, the pupperleft points to an empty object. There is also a floating phenomenon.

Therefore, this is why the function assumes that "returning a handle represents the inner component of an object" is always a critical cause.

Please remember:

(1) Avoid returning handles to the inside of the object. Adhering to this clause adds encapsulation, helps the const member function to be more like a const, and minimizes the possibility of a "virtual number card".

Effective C + +: Clause 28: Avoid returning handles point to internal members of an object