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

Предпочитайте полиморфизм, а не крупномасштабную проверку типов

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

Пример кода, который следовало бы заменить вызовом полиморфного метода (С++)

switch ( shape.type ) { case Shape Circle:

shape.DrawCircle();

break; case Shape Square:

shape.DrawSquare();

break;

Здесь методы shape.DrawCircleQ и shape.DrawSquareQ следует заменить на единственный метод shape.DrawQ, поддерживающий рисование и окружностей, и прямоугольников.

С другой стороны, иногда блоки case служат для разделения по-настоящему разных видов объектов или форм поведения. Так, следующий фрагмент вполне уместен в объектно-ориентированной программе:

Пример кода, который, пожалуй, не следует заменять вызовом полиморфного метода (С++)

switch ( ui.Commancl() ) { case Connancl OpenFile:

OpenFile();

break; case Commancl Print:

PrintO;

break; case Conmancl Save;

SaveO;

break; case Comnfiancl Exit:

ShutDownO;

break;

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

ции это неуместно: имя метода DoCommandQ было бы настолько туманным, что почти утратило бы всякий смысл, тогда как блоки case довольно информативны.

Делайте все данные закрытыми, а не защищенными Как говорит Джошуа Блох, «наследование нарушает инкапсуляцию» (Bloch, 2001). Выполняя наследование от класса, вы получаете привилегированный доступ к его защищенным методам и данным. Если производному классу на самом деле нужен доступ к атрибутам базового класса, включите в базовый класс защищенные методы доступа.

Множественное наследование

Наследование - мощный и... довольно опасный инструмент.

С множественным наследование

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

единичном нашдоши».

Если наследование - цепная пила, то множественное на-

следование - это старинная цепная пила с барахлящим Meyers)

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

Некоторые эксперты рекомендуют широкое применение множественного наследования (Meyer, 1997), но по опыту могу сказать, что оно полезно главным образом только при создании «миксинов» - простых классов, позволяющих добавить ряд свойств в другой класс. Миксины называются так потому, что они позволяют «подмешать (mix in)» свойства в производные классы. Миксинами могут быть классы вроде Displayable, Persistent, Serializable или Sortable. Миксины почти всегда являются абстрактными и не поддерживают создания экземпляров независимо от других объектов.

Миксины требуют множественного наследования, но пока все миксины по-настоящему независимы друг от друга, вы можете не бояться классической проблемы, связанной с ромбовидной схемой наследования. Кроме того, «объединяя» атрибуты, они делают проект системы понятнее. Программисту легче разобраться с объектом, использующим миксины Displayable и Persistent, а не 11 более конкретных методов, которые понадобились бы для реализации этих двух свойств в противном случае.

Похоже, разработчики Java и Visual Basic понимали ценность миксинов, разрешив множественное наследование интерфейсов, но только единичное наследование классов. С++ поддерживает множественное наследование и интерфейсов, и реализации. Используйте множественное наследование, только тщательно рассмотрев все альтернативные варианты и проанализировав влияние выбранного подхода на сложность и понятность системы.

Почему правил наследования так много?

в этом разделе были описаны многие правила избавления от проблем, связанных с наследованием. Все эти правила подразумевают, что наследование часто противоречит главному техническому императиву програм-

жирования - управлению сложностью. Ради управления сложностью относитесь к наследованию с подозрением. Вот как использовать наследование и включение:

1 если несколько классов имеют общие данные, но не фор-

нош ем шдраадбй «Гшемый поведения, создайте общий объект, который можно было

Технический «мператйв Разра- ь! включить во все эти классы;

боткй ПО: управление сложно- если несколько классов имеют общие формы поведения, стыо» раздела $.2. данные, сделайте эти классы производными от общего

базового класса, определяющего общие методы;

если несколько классов имеют общие данные и формы поведения, сделайте эти классы производными от общего базового класса, определяющего общие данные и методы;

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

Методы-члены и данные-члены

Ниже я даю несколько советов по эффективной реализации Першиаяшша О методах

ш общем см. ттщ 7- методов-членов и данных-членов.

Включайте в класс как можно меньше методов

В одном исследовании программ на С++ было обнаружено, что большему числу методов в расчете на один класс соответствует большее число изъянов (Basili, Briand, and Melo, 1996). Однако важнее оказались другие конкурирующие факторы, в том числе многоуровневые иерархии наследования, большое число методов, вызываемых из класса, и сильное сопряжение между классами. Разрабатывая класс, стремитесь к оптимальному соответствию между этими факторами и минимальным числом методов.

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

Минимизируйте число разных методов, вызываемых классом Одно исследование показало, что число дефектов в коде класса статистически коррелирует с общим числом методов, вызываемых классом (Basili, Briand, and Melo, 1996). To же исследование показало, что число дефектов в коде класса повышается и при увеличении числа используемых в нем классов. Эти концепции иногда называют «коэффициентом разветвления по выходу (fan out)».

Избегайте опосредованных вызовов методов других классов Непосредственные связи довольно опасны. Опосредованные связи, такие как account.Con-tactPersonO.DaytimeContactlnpOPboneNumberO, опасны еще больше. В связи с этим ученые сформулировали «Правило Деметры (Law of Demeter)» (Lieberherr and Holland, 1989), которое гласит, что Объект А может вызывать любые из собственных методов. Если он создает Объект В, он может вызывать любые методы Объекта