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

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

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

Мейер Б.

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

2

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

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

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

3

Объектно-ориентированная методология: Правильно применяйте
метод

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

О методологии

Следующие несколько лекций с 1-й по 11-ю, составляющие часть этого курса,
полностью посвящены методологии. В них исследуются проблемы, возникающие при
создании ОО-проектов: как находить классы, как не делать ошибок при использовании
наследования, роль и место ОО-анализа, фундаментальные идеи проектирования
(“образцы”), как учить Методу, новый цикл жизни ПО. В результате, я надеюсь, придет
понимание того, как наилучшим образом использовать преимущества ОО-техники,
изученной в предыдущих лекциях курса “Основы объектно-ориентированного
программирования”.

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

Методология: что и почему

Люди верят заповедям. Сражения за незыблемые “Принципы Истинной Веры” не
являются чем-то новым и характерны не только для разработчиков ПО.

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

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

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

4

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

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

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

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

Как создавать хорошие правила: советы советчикам

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

Необходимость методологических руководств

Методология разработки ПО не является новой областью. Ее истоки восходят к
известной работе Дейкстры “Go To Statement Considered Harmful” ( О вреде оператора
Go To ) и последующим работам этого же автора и его коллег по структурному
программированию. Но не все последующие методологические работы поддерживают

5

достигнутый уровень стандартов.

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

Теория

Первая обязанность советчика - давать совет, согласующийся с предметной областью:

Теоретический базис: принцип методологии

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

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

Практика

Теория - это дедуктивная часть методологии ПО. Но правила, основанные только на
теории, могут быть опасными. Эмпирическая компонента столь же важна:

Практический базис: принцип методологии

Правила методологии ПО должны основываться на широком практическом опыте.

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

здесь опыт незаменим.

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

Опыта, анализа или даже анализа и проектирования явно недостаточно. Не один раз
приходилось видеть, как консультанты по анализу выполняли свою работу, получали
плату, и оставляли компанию с не более чем схемами с квадратиками и стрелками документом анализа. А затем компания должна была извлекать нечто полезное из этих
кусочков и делать свою трудную работу; иногда работа аналитиков оказывалась
полностью бесполезной, поскольку не учитывала важных практических ограничений.
Подход “только анализ” противоречит фундаментальным идеям бесшовности
(seamlessness) и обратимости (reversibility), интегрированному жизненному циклу,
характерному для объектной технологии, где анализ и проектирование свиваются с
реализацией и сопровождением. Кто не прошел все этапы этого пути, вряд ли может
давать методологические советы.

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

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

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

Повторное использование: принцип методологии

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

Типология правил

Обратимся теперь к форме методологических правил. Какой вид советов является
эффективным?

Правило может быть рекомендацией ( advisory ) - приглашением следовать

7

определенному стилю, или абсолютным ( absolute ) - предписывающим выполнять
работу определенным образом. Правило может быть выражено в положительной (
positive ) форме - говорящей, что следует делать, или в отрицательной ( negative )
форме - чего не следует делать. Это дает нам четыре вида:

Классификация методологических правил

Абсолютно положительное: “Всегда делай a “.
Абсолютно отрицательное: “Никогда не используй b “.
Рекомендательно положительное: “Используй c, если это возможно”.
Рекомендательно отрицательное: “Избегай d, если это возможно”.

В каждом случае требования слегка отличаются.

Абсолютная положительность

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

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

Абсолютная положительность: принцип методологии

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

Абсолютная отрицательность

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

Абсолютная отрицательность: принцип методологии

8

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

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

Рекомендательные правила, положительные или отрицательные, несут в себе риск
бесполезности.

Чтобы отличить принцип от обычной банальности ( platitude ), следует рассмотреть
отрицание: для принципов отрицание имеет смысл независимо от того, согласны вы с
ним или нет. Например, часто цитируемый методологический совет: “Используйте
имена переменных, имеющие смысловое содержание”, - не является принципом с этой
точки зрения, так как никто в здравом уме не будет выбирать бессмысленные имена
переменных. Для превращения этого правила в принцип, следует задать точный
стандарт именования переменных. Конечно, поступив так, вы обнаружите, что
некоторые читатели не будут согласны с предложенным стандартом, - вот почему
банальности более комфортабельны, но методологи должны брать на себя подобные
риски.

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

Следующее предписание позволит избежать этого риска, сохраняя нашу честность:

Рекомендательные правила: принцип методологии

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

Вот пример отрицательной рекомендации, извлеченный из обсуждения преобразования
типов ( casts ) в одном из справочников по C++:

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

Все это не сопровождается пояснением, как же выяснить, что ” программист
действительно был прав “. Так что читателю предлагается не использовать некоторый
механизм языка ( type casts ), предупреждая, что это может быть опасно и ”
приводить к сюрпризам “, неявно заявляя, что иногда этот механизм следует
применять, не давая никакого указания, как различать случай легитимного

9

использования.

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

Исключения

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

В одной из статей по методологии ПО после представления довольно строгого
множества правил приводится следующий абзац:

Строгая версия формы класса, вытекающая из закона Деметры (см. курс ссылка:
Основы объектно-ориентированного программирования - /department/se/oopbases/),
предназначена быть нормой, хотя это и не является абсолютным ограничением.
Минимизированная версия законной формы класса дает нам выбор, насколько мы
хотим следовать строгой версии закона: чем больше классов с непредпочтительным
знакомством вы используете, тем менее следует придерживаться строгой формы. В
некоторых ситуациях цена соблюдения строгой версии может быть выше тех
преимуществ, которые она предоставляет.

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

Что ошибочного, если исключения не присутствуют в общих руководствах? Поскольку
проектирование ПО является сложной задачей, то иногда необходимо (хотя всегда
нежелательно) к абсолютно положительному правилу ” Всегда делай X в ситуации A ”
или к абсолютно отрицательному ” Никогда не делай Y в ситуации A ” добавлять
квалификацию ” за исключением случаев B , C и D “. Такое квалифицированное правило
остается абсолютно положительным или отрицательным: просто его область
применения сужается, теперь это не все A, но A лишенное B, C и D. Расплывчатая
формулировка исключений неприемлема (” в некоторых ситуациях потери могут быть
больше преимуществ ” - что это за ситуации?). Позже в цитируемой статье показан
пример, нарушающий правило, но исключение проверяется в терминах, специально
подобранных для данного случая, а оно должно быть частью правила:

Включение исключений: принцип методологии

Если методологическое правило представляет общеприменимое руководство,

10