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

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

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

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

---

Отношение "является" изучалось, в основном, с точки зрения приложений искусственного интеллекта в [Brachman 1983].

Формальное изучение наследования и его семантики проведено в [Cardelli 1984].

Соглашение об использовании для переопределения двойного плюса пришло из системы обозначений Business Object Notation, предложенной Nerson'ом и Walden'ом (ссылки в лекции 9 курса "Основы объектно-ориентированного проектирования").

Конструкция Precursor (аналогичная конструкции super в языке Smalltalk, но с важным отличием, разрешающим ее использовать только для переопределения процедур) является результатом неопубликованной совместной работы с Roger Browne, James McKim, Kim Walden и Steve Tynor.

Упражнения

У14.1 Многоугольники и прямоугольники

Дополните версии классов POLYGON и RECTANGLE, наброски которых приведены в начале лекции. Включите в них подходящие процедуры создания.

У14.2 Многоугольник с малым числом вершин

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

У14.3 Геометрические объекты с двумя координатами

Опишите класс TWO_COORD, задающий объекты с двумя вещественными координатами, среди наследников которого были бы классы POINT (ТОЧКА), COMPLEX (КОМПЛЕКСНОЕ_ЧИСЛО) и VECTOR (ВЕКТОР). Будьте внимательны при помещении каждого компонента на подходящий для него уровень иерархии.

У14.4 Наследование без классов

В этой лекции были представлены два взгляда на наследование: будучи модулем, класс-наследник предлагает службы своего родителя плюс еще некоторые, будучи типом, он реализует отношение "является" (каждый экземпляр наследника является также экземпляром каждого из родителей). "Пакетами" модульных, но не ОО-языков (таких как Ада (Ada) или Модула-2 (Modula-2)) являются модули, но не типы. При первой интерпретации к ним можно было бы применить наследование. Обсудите, в каком виде наследование может быть введено в модульные языки. Не забудьте рассмотреть при этом принцип Открыт-Закрыт.

У14.5 Классы без объектов

Не разрешается создавать объекты отложенных классов. В одной из предыдущих лекций был указан другой способ создания класса без объектов: включить в него пустую процедуру создания. Эквивалентны ли эти два механизма? Можно ли выделить случаи, когда использование одного из них предпочтительнее, чем другого? (Указание: в отложенном классе должен быть хоть один отложенный компонент.)

У14.6 Отложенные классы и прототип

Отложенные классы нельзя инициализировать. С другой стороны, были приведены аргументы в пользу того, чтобы в первой версии класса в проекте все компоненты оставались отложенными. Может появиться желание "выполнить" такой проект: при проектировании ПО иногда хочется вступить в игру как можно раньше, исполнить неполные реализации, чтобы получить практический опыт и проверить некоторые аспекты системы даже при неполностью реализованных других аспектах. Обсудите доводы за и против того, чтобы иметь в компиляторе специальную параметр "прототип", позволяющий инициализировать отложенный класс и выполнить отложенный компонент (как пустую операцию). Обсудите детали.

У14.7 Библиотека поиска в таблицах (семестровый проект)

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

У14.8 Виды отложенных компонентов

Может ли атрибут быть отложенным?

У14.9 Комплексные числа

(Это упражнение предполагает знакомство со всеми лекциями вплоть до 5-й курса "Основы объектно-ориентированного проектирования".) В примере, рассмотренном при обсуждении интерфейса модулей, использовались комплексные числа с двумя разными представлениями, при этом соответствующие изменения в представлениях остались "за кадром". Определите можно ли получить эквивалентный результат с помощью наследования, а именно, создать класс COMPLEX (КОМПЛЕКСНЫЕ) и его наследников CARTESIAN_COMPLEX (КОМПЛЕКСНЫЕ_В_ДЕКАРТОВЫХ_КООРДИНАТАХ) и POLAR_COMPLEX (КОМПЛЕКСНЫЕ_В_ПОЛЯРНЫХ_КООРДИНАТАХ).

Лекция 15. Множественное наследование

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

Примеры множественного наследования

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

[x]. потребность в смене имен компонентов, которая может оказаться полезной и при единичном наследовании;

[x]. дублируемое (repeated) наследование, при котором два класса связаны отношением предок-потомок более чем одним способом.

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

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

Пример, неподходящий для введения

Сначала покончим с одним бытующим заблуждением. Для этого рассмотрим пример, приводимый (в том или ином виде) во многих статьях, книгах и лекциях, но зачастую порождающий недоверие к множественному наследованию. И дело не в том, что этот пример неверен; просто при первом знакомстве с проблемой он не может служить иллюстрацией, поскольку являет собой образец нетипичного применения этого механизма.

В стандартной формулировке примера речь заходит о классах TEACHER и STUDENT, и вам тут же предлагают отметить тот факт, что отдельные студенты тоже преподают, и советуют ввести класс TEACHING_ASSISTANT, порожденный от TEACHER и STUDENT.

Рис. 15.1.  Пример множественного наследования

Выходит, в этой схеме что-то не так? Не обязательно. Но как начальный пример он весьма неудачен. Все дело в том, что STUDENT и TEACHER - не отдельные абстрактные понятия, а вариации на одну тему UNIVERSITY_PERSON. Поэтому, увидев картину в целом, мы обнаружим пример не просто множественного, но дублируемого (repeated) наследования - схемы, изучаемой позже в этой лекции, в которой класс является правильным наследником другого класса двумя или более различными путями:

Рис. 15.2.  А это пример дублируемого наследования

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

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