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

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

Для решения этих проблем нам понадобится вся мощь ОО-концепций.

Ключевые концепции

[x]. Для разработки ПО характерна повторяющаяся деятельность, включающая частое использование общих образцов (common patterns). Но имеются существенные вариации того, как используются и комбинируются эти образцы, так примитивные попытки работать с компонентами, имеющимися в наличии, терпят неудачу.

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

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

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

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

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

[x]. Два метода позволяют повысить гибкость пакетов: перегрузка подпрограмм и универсальность.

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

[x]. Универсальность способствует повторному использованию, но решает лишь проблему изменчивости типов.

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

Библиографические замечания

Первая публикация, обсуждающая проблемы повторного использования, упомянутая в начале этой лекции, принадлежит, по-видимому, Мак-Илрою (McIlroy's 1968 Mass-Produced Software Components). Его статья [McIlroy 1976] была представлена в 1968 г. на первой конференции по разработке ПО, созванной Комитетом НАТО по науке (NATO Science Affairs Committee). 1976 г. это дата издания трудов конференции, [Buxton 1976], публикация которых была задержана на несколько лет. Мак-Илрой пропагандировал развитие промышленного производства компонентов ПО.

Вот фрагмент его статьи:

'Производство ПО в наши дни оказывается по уровню индустриализации ниже наиболее отсталых отраслей строительной промышленности. Я думаю, что его надлежащее место значительно выше, и хотел бы выяснить перспективы реализации методов массового производства ПО ... Когда мы беремся за написание компилятора, то начинаем с вопроса: 'Какой механизм работы с таблицами будем создавать?'. А следует задавать вопрос: 'Какой механизм будем использовать?' ... Я выдвигаю тезис о том, что у индустрии программ слабая основа отчасти в связи с отсутствием подотрасли производства программных компонентов... Такое производство компонентов могло бы быть весьма успешным.'

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

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

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

Специальный выпуск Transactions on Software Engineering, изданный Биггерстафом и Перлисом (Biggerstaff and Perlis) [Biggerstaff 1984], сыграл важную роль в привлечении внимания сообщества разработчиков ПО к вопросам повторного использования; смотрите в частности, в этом выпуске, статьи [Jones 1984], [Horowitz 1984], [Curry 1984], [Standish 1984] и [Goguen 1984]. Те же издатели включили все эти статьи (кроме первой из вышеупомянутых) в расширенный двухтомный сборник [Biggerstaff 1989]. Еще одним сборником статей по повторному использованию является [Tracz 1988]. Позже Трач (Tracz) собрал ряд своих материалов из IEEE Computer в полезную книгу [Tracz 1995], в которой особое значение придается организационным вопросам.

Один из подходов к повторному использованию, основанный на идеях искусственного интеллекта, воплощен в проекте Массачусетского технологического института по подготовке программистов (MIT Programmer's Apprentice project); смотрите статьи [Waters 1984] and [Rich 1989], воспроизведенные в первом и втором сборниках Биггерстафа-Перлиса, соответственно. Эта система использует не реальные повторно используемые модули, а шаблоны (называемые cliches and plans), представляющие общие стратегии разработки программы.

При обсуждении вопроса о пакетах упоминались три 'языка с инкапсуляцией': Ada, Modula-2 и CLU. Язык Ada обсуждается в одной из последующих лекций, библиографический раздел которой содержит ссылки на языки Modula-2, CLU, а также Mesa and Alphard, причем два последних языка с инкапсуляцией принадлежат 'модульному поколению' семидесятых и начала восьмидесятых годов прошлого века. Эквивалент пакета в языке Alphard был назван формой (form).

Важный проект STARS Министерства обороны США восьмидесятых годов прошлого века был акцентирован на проблеме повторного использования, особенно на организационных аспектах этой