Бертран Мейер - Основы объектно-ориентированного программирования

• Название: Основы объектно-ориентированного программирования
• Автор: Бертран Мейер
• Жанр: Прочая околокомпьтерная литература

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

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

---

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

На рисунке показана часть плоской формы класса LINKED_TREE из библиотеки Base. Результат получен с применением Class Tool в среде разработки ISE. Для повторения результата настройте Class Tool на LINKED_TREE и щелкните по кнопке формата Flat.

Рис. 15.14.  Отображение плоской формы

Применение плоской формы

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

Кроме того, она может оказаться полезной при построении автономной версии класса, не обремененной историей порождения. Потеря полиморфизма снижает ценность такого класса.

Краткая плоская форма

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

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

Объединение двух понятий дает новое понятие краткой плоской формы (flat-short form). Как и краткая форма класса, она содержит лишь общедоступную информацию, в ней не указаны скрытые компоненты, а для экспортируемых компонентов не приводится реализация, в частности, предложения do. Как и плоская форма, краткая плоская форма задает все компоненты класса - и унаследованные, и описанные в нем самом.

Краткая плоская форма является основным методом документирования классов, в том числе повторно используемых классов библиотек. В этом виде информация о классе становится доступна его клиентам (и тем, кто занимается сопровождением класса). Краткая плоская форма служит для описания всех классов в библиотеке Base [M 1994a].

Дублируемое наследование

Дядюшка Жак: С кем желаете Вы говорить, сударь, с конюхом или с поваром? Ибо я у Вас и то, и другое.

Мольер, "Скупой"

Дублируемое наследование (repeated inheritance) возникает, когда класс является потомком другого класса более чем на одном пути наследования. При этом возникает потенциальная неоднозначность, которую и следует разрешить.

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

Общие предки

Множественное наследование не запрещает, например, того, чтобы класс D был наследником классов B и C, каждый из которых является потомком класса A. Эту ситуацию и называют дублируемым наследованием.

Рис. 15.15.  Дублируемое наследование

Если B и C наследники потомков A, (случай 1), то такое наследование именуется косвенным. Если A, B и C - это один класс (случай 2), - наследование именуется прямым, что может быть записано в виде:

class D inherit

A

A

...

feature

...

end

По обе стороны океана

Следующий пример позволит нам промоделировать ситуацию дублируемого наследования и изучить возникающие проблемы. Пусть класс DRIVER имеет атрибуты:

age: INTEGER

address: STRING

violation_count: INTEGER -- Число записанных нарушений

и методы:

pass_birthday is do age := age + 1 end

pay_fee is

-- Оплата ежегодной лицензии.

do ... end

Класс наследник, US_DRIVER учитывает налоговое законодательство США, другой, FRENCH_DRIVER, - налоговое законодательство Франции.

Рассмотрим категорию людей, которым в течение года приходится водить машину в обеих странах. Нужного класса у нас еще нет, и простым решением этой проблемы кажется множественное наследование. Опишем класс FRENCH_US_DRIVER как порожденный от US_DRIVER и FRENCH_DRIVER. Налицо дублируемое наследование.

Рис. 15.16.  Типы водителей

Совместное использование и репликация

Из приведенного примера вытекает основная проблема дублируемого наследования: каков смысл компонентов дублируемого потомка (FRENCH_US_DRIVER), полученных от дублируемого предка (DRIVER)?

Рассмотрим компонент age. Он наследуется от обоих потомков DRIVER, так что, на первый взгляд, возникает конфликт имен, требующий переименования. Однако такое решение было бы неадекватно проблеме, так как реального конфликта здесь нет - атрибут age унаследованный от DRIVER, задает возраст водителя, и он один и тот же для всех потомков (если только не менять свои данные в зависимости от страны пребывания). То же относится к процедуре pass_birthday.

Внимательно перечитайте правило о конфликте имен:

Класс, наследующий от разных родителей различные компоненты с идентичным именем, некорректен.

Компоненты age (также как и pass_birthday), наследованные классом FRENCH_US_DRIVER от обоих родителей, не являются "различными", поэтому реального конфликта не возникает. Заметьте, неоднозначность могла бы возникнуть лишь в случае переопределения компонента в одном из классов. Чуть позже мы покажем, как справиться с этой проблемой, а пока предположим, что переопределений не происходит.

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

Всегда ли применяется совместное использование? Нет. Рассмотрим компоненты address, pay_fee, violation_count. Обращаясь в службу регистрации автотранспорта в разных странах, водители скорее всего будут указывать разные адреса и по-разному платить ежегодные сборы. Впрочем, и нарушения правил тоже будут различны. Каждый из таких компонентов, следует представить в дублируемом потомке двумя разными компонентами. Данный случай будем называть репликацией (replication).

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

Чтобы совместно использовать один из компонентов, достаточно под одним именем унаследовать исходную версию этого компонента от обоих родителей. Но как реализовать репликацию? Делая все наоборот: породив один компонент под двумя разными именами.

Эта идея не противоречит общему правилу, согласно которому каждое имя в классе служит обозначением лишь одного компонента. Поэтому репликация компонента означает переименование при наследовании.

Правило дублируемого наследования

У дублируемого потомка версии дублируемого компонента, наследуемые под одним и тем же именем, представляют один компонент. Версии, наследуемые под разными именами, представляют разные компоненты, являясь репликацией оригинала дублируемого предка.

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

За исключением особых случаев, включающих переопределение, репликация может носить только концептуальный характер: фактического дублирования кода не происходит, но дублируемый потомок имеет доступ к двум компонентам.