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

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

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

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

---

[x]. Совместимость. Если использовать хорошую современную ОО-библиотеку, то ее стиль повлияет, за счет естественного "процесса диффузии", на стиль разработки всего ПО. Это существенно помогает повысить качество программного продукта.

[x]. Инвестирование. Создание повторно используемого ПО позволяет сберечь плоды знаний и открытий лучших разработчиков, превращая временные ресурсы в постоянные.

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

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

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

Потребители и производители повторно используемых программ

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

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

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

Дорога к Повторному использованию

Станьте потребителем повторного использования, прежде чем пытаться стать его производителем.

Что следует повторно использовать?

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

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

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

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

Ввиду высокой текучести программистских кадров возможности такого подхода ограничены.

Повторное использование проектов и спецификаций

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

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

Эти замечания можно отнести и к другому смежному виду повторного использования: повторному использованию спецификаций.

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

Термин "преодолеть" здесь является, пожалуй, слишком сильным, поскольку, как это часто бывает в подобных спорах, свою долю в достижение полезного результата внесли обе стороны. Идея повторного использования проектов становится намного более интересной при использовании подхода (такого, как точка зрения на ОО-технологию, развиваемая в этой книге), который существенно устраняет разрыв между проектом и его реализацией. Тогда разница между модулем и проектом модуля (design for a module) является не принципиальной, а лишь количественной: проект модуля это просто модуль, отдельные фрагменты которого еще не полностью реализованы; а полностью реализованный модуль можно использовать, благодаря средствам абстрактного представления, в качестве проекта модуля. При таком подходе различие между повторным использованием модулей (рассматриваемым ниже) и повторным использованием проектов постепенно исчезает.

Образцы проектов (design patterns)

В середине девяностых годов специалистов привлекла идея образцов (или шаблонов) проектов. Образец - это архитектурный принцип, применимый во многих прикладных областях; следуя образцу можно построить решение некоторой проблемы.(Образец проекта с историей команд рассмотрен в лекции 3 курса "Основы объектно-ориентированного проектирования".)

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

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

Образцы проектов уже внесли существенный вклад в развитие ОО-технологии, и по мере публикации все новых образцов они помогут разработчикам пользоваться опытом своих предшественников и современников. Как же этот общий принцип приложить к проблеме повторного использования? Образцы проектов не должны внушать надежду на возвращение к уже упоминавшейся ранее мысли о том, что "все что нужно - это только повторно использовать проекты". Образец, который по-существу представляет собой лишь сценарий образца (book pattern), пусть даже самый лучший и универсальный, является только "учебным пособием", а не инструментальным средством повторного использования. Как-никак, а в течении трех последних десятилетий учебники по компьютерным наукам рассказывают об оптимизации реляционных баз данных, AVL-деревьях (сбалансированных деревьях Адельсона-Вельского и Ландиса), алгоритме быстрой сортировки (Quicksort) Хоара, алгоритме Дейкстры для поиска кратчайшего пути в графе, без какого-либо упоминания о том, что эти мет оды совершили прорыв в решении проблемы повторного использования. В определенном смысле, образцы, разработанные за последние несколько лет, являются лишь очередными дополнениями к набору стандартных приемов, используемых специалистами по разработке ПО. При таком понимании новым вкладом в ОО-технологию следует считать не идею образца, а сами предлагаемые образцы.