Часть II. Объектно-ориентированное программирование

}:

void demo(B* p){

if (typeid(*p) « typeid(O)

dynamic_cast<C*>(p)->some_method();

}

int main(){

С* с = new C; demo(c); return 0; } Информацию о типе полезно использовать и в диагностических целях:

void print_type(some_obj *p){ cout « typeid(*p).name();

} Операция typei d не должна применяться вместо виртуальных функций и в случаях, когда тип объекта можно определить на этапе компиляции.

Глава 9

Рекомендации

по программированию

В этой части были рассмотрены объектно-ориентированные возможности языка C++, и теперь пришло время остановиться на проблемах, которые возникают в процессе написания программ: какие средства языка предпочтительнее выбирать в разных случаях, на что обратить особое внимание, чего нужно избегать, чтобы программа получилась эффективной и легко сопровождаемой.

Однозначные рекомендации, как всегда, дать невозможно — только понимание механизма работы C++ позволит грамотно его использовать.

Создание любого программного продукта начинается с процесса проектирования, и одна из первых задач, возникающих при этом, — определить, должна программа быть объектно-ориентированной или нет. Объектно-ориентированное программирование, примененное к задаче, в которой в нем нет необходимости, только увеличит объем программы и сложность ее написания. Если в процессе анализа постановки задачи выясняется, что необходимости в иерархии классов нет, чаще всего можно обойтись структурным подходом. Б. Страуструп считает, что «везде, где не нужно более одного объекта определенного типа, достаточно стиля программирования с сокрытием данных при помощи модулей».

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

Технологии проектирования программ посвящено много литературы, и освещение этого вопроса не входит в задачу данной книги. Тем, кто собирается приниматься за серьезные программные проекты, рекомендуется предварительно изучить ставшие классическими книги Ф. Брукса [6], Г. Буча [7] и Б. Страуструпа [17]. Далее рассматриваются вопросы, на которые следует обращать внимание на следующем этапе создания программы — в процессе написания программного кода.

При создании класса, то есть нового типа данных, следует хорошо продумать его интерфейс — средства работы с классом, доступные использующим его программистам. Интерфейс хорошо спроектированного класса интуитивно ясен, непро-

242

Часть II. Объектно-ориентированное программирование

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

Не следует определять методы типа get/set для всех скрытых полей класса — это все равно, что открыть к ним доступ, только более сложным способом. Важно помнить, что поля класса вводятся только для того, чтобы реализовать свойства класса, представленные в его интерфейсе с помощью методов. Конечно, нет ничего плохого в том, чтобы установить или получить значение некоторого поля с помощью метода, если таким образом реализуется свойство класса (таким образом, код будет тот же, а его смысл — совсем другим).

Не нужно расширять интерфейс класса без необходимости, «на всякий случай», поскольку увеличение количества методов ведет к трудности понимания класса пользователем¹. В идеале интерфейс должен быть полным, то есть предоставлять возможность выполнить любые разумные действия с классом, и минимальным — без дублирования и пересечения возможностей методов.

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

Для увеличения производительности программы наиболее часто вызываемые методы можно объявить как встроенные (inline). В основном это касается коротких методов, тело которых оказывается меньше размера кода, генерируемого для их вызова. Кроме ускорения программы за счет исключения вызовов, это дает возможность компилятору производить более полную оптимизацию. Однако необходимо учитывать, что директива inline носит для компилятора рекомендательный характер, и он может ей не последовать — например, если метод содержит сложные циклы или объявлен как виртуальный. Кроме того, если программа или компилятор используют указатель на метод или функцию, дополнительно будет сгенерирована их невстраиваемая копия. Еще одним соображением, которое требуется принимать во внимание, является то, что многие отладчики имеют проблемы со встраиваемыми функциями.

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

Под пользователем имеется в виду программист, использующий класс.