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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обстоятельное рассмотрение проблемы образцов показывает, что эта точка зрения оказывается излишне ограниченной (См. "Программы с дырами", лекция 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 будут рассмотрены их свойства.

Оглавление книги