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

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

Но использование ОО-технологии обеспечивает радикальный вклад - она позволяет создавать повторно используемые модули, обладающие способностью изменяться. Они не будут "замороженными" элементами, а служат общими схемами, образцами, - здесь действительно уместен термин образецв полном смысле этого слова, они могут быть адаптированы к различным конкретным ситуациям. Это новое понятие мы называем классом, определяющим поведение (behavior class)(более образным является термин программы с дырами (programs with holes)). Это понятие, основанное на понятии отложенного (абстрактного) класса (deferred class), будет рассмотрено в последующих лекциях. Объединяя его с идей о группе компонентов, предназначенных для совместного функционирования - часто называемых каркасами (frameworks)или просто библиотеками- получаем замечательное средство, сочетающее повторное использование и способность к адаптации.

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

Если так, то в какой же форме следует их использовать? Естественный ответ - в первоначальной форме: в виде исходного текста. В некоторых случаях такой подход оказался весьма эффективным. Например, совершенствование операционной системы Unix, первоначально распространявшейся по университетам и исследовательским лабораториям, стало возможным в основном благодаря наличию исходного кода, получаемого в режиме онлайн. Это позволило пользователям изучать, копировать и расширять сферу использования системы. То же справедливо и для круга пользователей Lisp.

Существуют экономические и психологические препятствия на пути к распространению исходных кодов. Более серьезными ограничениям являются:

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

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

Удовлетворяющая требованиям модульности форма повторного использования должна устранить эти ограничения, поддерживая абстракцию и обеспечивая "мелкоструктурную" реализацию повторного использования.

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

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

[x].Для повторного использования проектов необходимы не только готовые решения конкретных задач, но и достаточно высокий концептуальный уровень и универсальность повторно используемых компонентов. Классы, с которыми мы встретимся при обсуждении ОО-технологии, могут рассматриваться как модули-проекты, так и как модули-реализации.

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

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

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

Далее в лекциях 3-6 этого курса предлагается строгое определение таких абстрактных модулей; а затем в лекциях 7-18 будут рассмотрены их свойства.