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

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

2-е издание, исправленное

Мейер Б.

Национальный Открытый Университет “ИНТУИТ”
2016

2

Основы объектно-ориентированного программирования/ Б. Мейер - М.: Национальный Открытый
Университет “ИНТУИТ”, 2016

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

(c) ООО “ИНТУИТ.РУ”, 2005-2016
(c) Мейер Б., 2005-2016

3

Качество ПО

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

Внешние и внутренние факторы

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

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

Такие характеристики ПО, как модульность или читаемость, являются внутренними
факторами, понятными только для профессионалов, имеющих доступ к тексту ПО.

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

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

Обзор внешних факторов

Рассмотрим самые важные внешние факторы качества, стремление к которым есть
центральная задача ОО-построения ПО.

Корректность (Correctness)

4

Определение: корректность

Корректность - это способность ПО выполнять точные задачи так, как они определены
их спецификацией.

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

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

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

Рис. 1.1.  Слои в разработке ПО

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

В методе, описанном в нашем курсе, слоев даже больше: разработка ПО будет
основываться на библиотеках компонентов повторного использования, используемых
во многих приложениях.

5

Рис. 1.2.  Уровни в процессе разработки, включающем повторное использование

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

Многие практики полагают, что достижение корректности ПО связано с тестированием
и исправлением ошибок. Мы же более амбициозны: в дальнейших лекциях исследуется
ряд технических приемов, в частности типизация и метод утверждений, направленных
на построение ПО, корректного с самого начала. Исправление ошибок и тестирование,
конечно, остаются необходимыми как средства дополнительной проверки результата.
Можно было бы пойти дальше и принять совсем формальный подход к построению
ПО. Это не является целью наших лекций, как ясно из несколько “робких” терминов “проверять”, “гарантировать”, “обеспечивать”, используемых выше вместо слова
“доказывать”. Все же многие из описанных ниже технических приемов происходят
непосредственно от математических методов формальной спецификации и
верификации программ, проходя длинный путь к обеспечению идеала корректности.

Устойчивость (Robustness)

Определение: устойчивость

Устойчивость - это способность ПО соответствующим образом реагировать на
аварийные ситуации.

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

6

Рис. 1.3.  Устойчивость против корректности

Как видно из определения, устойчивость по своей природе более нечеткое понятие,
чем корректность. Невозможно сказать, как в случае с корректностью, что в аварийных
ситуациях система должна “выполнять свои задачи”, поскольку ситуации выходят за
пределы спецификации. Если бы эти задачи были известны, аварийный случай стал бы
частью спецификации, и мы бы снова вернулись в область корректности.

Это определение “аварийной ситуации” нам еще понадобится при изучении обработки
исключений (Об исключительных ситуациях см. лекция 12). Оно подразумевает, что
понятия нормальной и аварийной ситуации всегда относительны по отношению к
заданной спецификации; ситуация аварийна, если она выходит за рамки
спецификации. Если расширить спецификацию, аварийные случаи становятся
нормальными - даже если они соответствуют таким нежелательным событиям, как,
например, ошибочный ввод пользователя.

Термин “нормальный” в этом смысле не означает “желательный”, а просто
“запланированный в проекте ПО”. Хотя на первый взгляд может показаться
парадоксальным, что ошибочный ввод может называться нормальным случаем, любой
другой подход опирается на субъективные критерии и, таким образом, бесполезен.

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

Расширяемость (Extendibility)

Определение: расширяемость

Расширяемость - это легкость адаптации ПО к изменениям спецификации.

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

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

7

карточный дом, удаление одного элемента может привести к разрушению всего
построения.

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

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

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

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

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

Повторное использование (Reusability)

Определение: повторное использование

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

Необходимость и возможность повторного использования возникает из наблюдений
сходства систем - системы ПО часто имеют похожую схему. Следует использовать это
сходство и не изобретать велосипед заново. Понимание этой схемы даст возможность
повторно применять созданный элемент ПО во многих других разработках.

8

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

При создании индустрии ПО необходимость повторного использования становится
насущной проблемой.

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

Совместимость (Compatibility)

Определение: совместимость

Совместимость - это легкость сочетания одних элементов ПО с другими.

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

Ключ к совместимости находится в однородности построения и в стандартных
соглашениях на коммуникации между программами. Эти подходы включают:

Стандартные форматы файлов, как в системе Unix, где каждый текстовый файл это просто последовательность символов.
Стандартные структуры данных, как в системе Lisp, где все данные, а также
программы, представлены бинарными деревьями (называемыми списками).
Стандартные пользовательские интерфейсы, как в различных версиях Windows,
OS/2 и MacOS, где все инструменты опираются на единую парадигму для
коммуникации с пользователем, основанную на стандартных компонентах, таких
как окна, значки, меню и т. д.

Большая общность достигается при определении стандартных протоколов доступа ко
всем важным элементам, управляемым программами. Такова идея, лежащая в основе
абстрактных типов данных и ОО-подхода, а также так называемого связующего
программного обеспечения (middleware), например CORBA и Microsoft’s OLE-COM
(ActiveX).

Эффективность (Efficiency)

9

Определение: эффективность

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

Почти синонимом эффективности является слово “производительность” ( performance
). В программистском сообществе есть два типичных отношения к эффективности:

Некоторые разработчики одержимы проблемами производительности, что
заставляет их прилагать много усилий к предполагаемой оптимизации.
Существует общая тенденция недооценки вопросов эффективности, вытекающая
из справедливых убеждений, существующих в промышленности:”сделай
правильно, прежде чем сделать быстро” и “модель компьютера будущего года все
равно будет на 50% быстрее”.

Часто один и тот же человек в разное время высказывает разные типы отношения и
является то доктором Abstract, то мистером Microsecond - происходит раздвоение
личности, как в известной истории про доктора Джекила и мистера Хайда.

Где же истина? Разработчики часто явно излишне заботятся о микрооптимизации. Как
уже отмечалось, эффективность не дорого стоит, если ПО некорректно. Можно
привести новое изречение: “не беспокойтесь о быстродействии ПО, если оно к тому же
и неверно”. Забота об эффективности должна сопоставляться с другими целями,
такими как расширяемость и возможность повторного использования. Оптимизация
может сделать ПО настолько специализированным, что оно не будет годно для
повторного использования и в случаях изменения спецификации. Более того,
постоянно растущая мощь компьютерного оборудования позволяет нам слегка
расслабиться и не стараться использовать последний байт или микросекунду.

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

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

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