Правило 28: Избегайте возвращения «дескрипторов» внутренних данных

Правило 28: Избегайте возвращения «дескрипторов» внутренних данных

Представим, что вы работаете над приложением, имеющим дело с прямоугольниками. Каждый прямоугольник может быть представлен своим левым верхним углом и правым нижним. Чтобы объект 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; // см. в правиле 13

}; // информацию о tr1::shared_ptr

Поскольку пользователям класса Rectangle понадобится определять его координаты, то класс предоставляет функции upperLeft и lowerRight. Однако Point – это определенный пользователем тип, поэтому, помня о том, что передача таких типов по ссылке обычно более эффективна, чем передача по значению (см. правило 20), эти функции возвращают ссылки на внутренние объекты Point:

class Rectangle {

public:

...

Point& upperLeft() const { return pData->ulhc;}

Point& lowerRight() const { return pData->lrhc;}

...

};

Такой вариант откомпилируется, но он неправильный! Фактически он внутренне противоречив. С одной стороны, upperLeft и lowerRight объявлены как константные функции-члены, поскольку они предназначены только для того, чтобы предоставить клиенту способ получить информацию о точках Rectangle, не давая ему возможности модифицировать объект Rectangle (см. правило 3). С другой стороны, обе функции возвращают ссылки на закрытые внутренние данные – ссылки, которые пользователь может затем использовать для модификации этих внутренних данных! Например:

Point coord1(0, 0);

Point coord2(100,100);

const Rectangle rec(coord1, coord2); // rec – константный прямоугольник

// от (0, 0) до (100, 100)

rec.upperLeft().setX(50); // теперь rec лежит между

// (50, 0) и (100, 100)!

Обратите внимание, что пользователь функции upperLeft может использовать возвращенную ссылку на один из данных-членов внутреннего объекта Point для модификации этого члена. Но ведь ожидается, что rec – константа!

Из этого примера следует извлечь два урока. Первый – член данных инкапсулирован лишь настолько, насколько доступна функция, возвращающая ссылку на него. В данном случае хотя ulhc и lrhc объявлены закрытыми, но на самом деле они открыты, потому что на них возвращают ссылки открытые функции upperLeft и lowerRight. Второй урок в том, что если константная функция-член возвращает ссылку на данные, ассоциированные с объектом, но хранящиеся вне самого объекта, то код, вызывающий эту функцию, может модифицировать данные. (Все это последствия ограничений побитовой константности – см. правило 3.)

Такой результат получился, когда мы использовали функции-члены, возвращающие ссылки, но если они возвращают указатели или итераторы, проблема остается, и причины те же. Ссылки, указатели и итераторы – все это «дескрипторы» (handles), и возвращение такого «дескриптора» внутренних данных объекта – прямой путь к нарушению принципов инкапсуляции. Как мы только что видели, это может привести к тому, что константные функции-члены позволят модифицировать состояние объекта.

Обычно, говоря о внутреннем устройстве объекта, мы имеем в виду его данные-члены, но функции-члены, к которым нет открытого доступа (то есть объявленные в секции private или protected), также являются частью внутреннего устройства. Поэтому возвращать их «дескрипторы» тоже не следует. Иными словами, нельзя, чтобы функция-член возвращала указатель на менее доступную функцию-член. В противном случае реальный уровень доступа будет определять более доступная функция, потому что клиенты смогут получить указатель на менее доступную функцию и вызвать ее через такой указатель.

Впрочем, функции, которые возвращают указатели на функции-члены, встречаются нечасто, поэтому вернемся к классу Rectangle и его функциям-членам upperLeft и lowerRight. Обе проблемы, которые мы идентифицировали для этих функций, могут быть исключены простым применением квалификатора const к их возвращаемому типу:

class Rectangle {

public:

...

const Point& upperLeft() const { return pData->ulhc;}

const Point& lowerRight() const { return pData->lrhc;}

...

};

В результате такого изменения пользователи смогут читать объекты Point, определяющие прямоугольник, но не смогут изменять их. Это значит, что объявление константными функций upperLeft и lowerRight больше не является ложью, так как они более не позволяют клиентам модифицировать состояние объекта. Что касается проблемы инкапсуляции, то мы с самого начала намеревались дать клиентам возможность видеть объекты Point, определяющие Rectangle, поэтому в данном случае ослабление инкапсуляции намеренное. К тому же это лишь частичное ослабление: рассматриваемые функции дают только доступ для чтения. Доступ для записи по-прежнему запрещен.

Но даже и так upperLeft и lowerRight по-прежнему возвращают «дескрипторы» внутренних данных объекта, и это может вызвать проблемы иного свойства. В частности, возможно появление «висячих дескрипторов» (dangling handles), то есть дескрипторов, ссылающихся на части уже не существующих объектов. Наиболее типичный источник таких исчезнувших объектов – значения, возвращаемые функциями. Например, рассмотрим функцию, которая возвращает ограничивающий прямоугольник объекта GUI:

class GUIObject {...};

const Rectangle // возвращает прямоугольник по значению;

boundBox(const GUIObject& obj); // см. в правиле 3, почему const

Теперь посмотрим, как пользователь может применить эту функцию:

GUIObject *pgo; // pgo указывает на некий объект

... // GUIObject

const Point *pUpperLeft = // получить указатель на верхний левый

&(boundingBox(*pgo).upperLeft()); // угол его рамки

Вызов boundingBox вернет новый временный объект Rectangle. Этот объект не имеет имени, поэтому назовем его temp. Затем вызывается функция-член upperLeft объекта temp, и этот вызов возвращает ссылку на внутренние данные temp, в данном случае на один из объектов Point. В результате pUpperLeft указывает на этот объект Point. До сих пор все шло хорошо, но мы еще не закончили, поскольку в конце предложения возвращенное boundingBox значение – temp – будет разрушено, а это приведет к разрушению объектов Point, принадлежавших temp. То есть pUpperLeft теперь указывает на объект, который более не существует. Указатель PUpperLeft становится «висячим» уже в конце предложения, где он создан!

Вот почему опасна любая функция, которая возвращает «дескриптор» внутренних данных объекта. При этом не важно, является ли «дескриптор» ссылкой, указателем или итератором. Не важно, что она квалифицирована const. Не важно, что сама функция-член, возвращающая «дескриптор», является константной. Имеет значение лишь тот факт, что «дескриптор» возвращен, поскольку возникает опасность, что он «переживет» объект, с которым связан.

Это не значит, что никогда не следует писать функции-члены, возвращающие дескрипторы. Иногда это бывает необходимо. Например, operator[] позволяет вам обращаться к отдельному элементу строки или вектора, и работает он, возвращая ссылку на данные в контейнере (см. правило 3), которые уничтожаются вместе с контейнером. Но все же такие функции – скорее исключение, чем правило.

Что следует помнить

• Избегайте возвращать «дескрипторы» (ссылки, указатели, итераторы) внутренних данных объекта. Это повышает степень инкапсуляции, помогает константным функциям-членам быть константными и минимизирует вероятность появления «висячих дескрипторов».

Данный текст является ознакомительным фрагментом.



Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

Счетчики дескрипторов процессов

Из книги автора

Счетчики дескрипторов процессов Распространенной ошибкой программистов является пренебрежение закрытием дескрипторов после того, как необходимость в них отпала; это может стать причиной утечки ресурсов, что, в свою очередь, может приводить к снижению


Дублирование дескрипторов

Из книги автора

Дублирование дескрипторов Родительскому и дочернему процессам может требоваться различный доступ к объекту, идентифицируемому дескриптором, который наследует дочерний процесс. Кроме того, процессу вместо псевдодескриптора, получаемого с помощью функции GetModuleFileName или


Эффективные способы возвращения

Из книги автора

Эффективные способы возвращения Берегите энергию, когда возвращаетесь. Вместо того чтобы прыгать вверх по ступеням, поместите на них лестницы. На прыжки вверх по ступеням шахты тратится значительное количество энергии, поэтому используйте лестницы. Так вы сможете


15.7. Передача дескрипторов

Из книги автора

15.7. Передача дескрипторов Когда нам требуется передать дескриптор от одного процесса другому, обычно мы выбираем одно из двух решений:1. Дочерний процесс использует все открытые дескрипторы совместно с родительским процессом после вызова функции fork.2. Все дескрипторы


Избегайте повторного ввода данных

Из книги автора

Избегайте повторного ввода данных Если пользователь уже сообщил вам что-то о себе (например, имя), лучше запомнить эту информацию и не спрашивать ее повторно, например при последующей регистрации.Лучше самим заботливо вписать имя в соответствующее поле. Людей раздражает,


15.8. Передача дескрипторов

Из книги автора

15.8. Передача дескрипторов Когда мы говорим о передаче открытого дескриптора от одного процесса другому, обычно подразумевается одно из двух:? наследование всех открытых дескрипторов родительского процесса дочерним после вызова fork;? сохранение открытых дескрипторов при


68. Широко применяйте assert для документирования внутренних допущений и инвариантов

Из книги автора

68. Широко применяйте assert для документирования внутренних допущений и инвариантов РезюмеИспользуйте assert или его эквивалент для документирования внутренних допущений в модуле (т.е. там, где вызываемый и вызывающий код поддерживаются одним и тем же программистом или


1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой

Из книги автора

1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой Даже простейшую процедурную логику трудно проверить, однако весьма сложные структуры данных являются довольно простыми для моделирования и


1.6.14. Правило генерации: избегайте кодирования вручную; если есть возможность, пишите программы для создания программ

Из книги автора

1.6.14. Правило генерации: избегайте кодирования вручную; если есть возможность, пишите программы для создания программ Известно, что люди плохо справляются с деталями. Соответственно, любой вид ручного создания программ является источником задержек и ошибок. Чем проще и


1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой

Из книги автора

1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой Даже простейшую процедурную логику трудно проверить, однако весьма сложные структуры данных являются довольно простыми для моделирования и


1.6.14. Правило генерации: избегайте кодирования вручную; если есть возможность, пишите программы для создания программ

Из книги автора

1.6.14. Правило генерации: избегайте кодирования вручную; если есть возможность, пишите программы для создания программ Известно, что люди плохо справляются с деталями. Соответственно, любой вид ручного создания программ является источником задержек и ошибок. Чем проще и


Обработка исходящих и внутренних документов

Из книги автора

Обработка исходящих и внутренних документов Исходящие и внутренние документы гораздо проще в обработке. Вся обработка заключается в их регистрации и передаче исполнителям либо отправке. Регистрация не отличается от описанной выше для входящих документов. Из состава


9.6.2.2. Переопределение дескрипторов (handle)

Из книги автора

9.6.2.2. Переопределение дескрипторов (handle) Когда программа начинает выполняться, пять дескрипторов (handle), соответствующих стандартным вводу, выводу, выводу сообщений об ошибках, порту и устройству печати, уже назначены. Пользователь может использовать значения этих