Пакеты - 4. Подходы к повторному использованию

Это окончание невероятной информации про .

...

либо написать собственную подпрограмму.

Пакеты

В семидесятые годы двадцатого века, в связи с развитием идей скрытия информации и абстракции данных, возникла необходимость в форме модуля, более совершенном, чем подпрограмма. Появилось несколько языков проектирования и программирования, наиболее известные из них: CLU, Modula-2 и Ada. В них предлагается сходная форма модуля, называемого в языке Ada пакетом, CLU - кластером, Modula - модулем. В нашем обсуждении будет использоваться термин пакет.4.4)

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

[x]. P1 В соответствии с принципом Лингвистических Модульных Единиц, "пакет" это конструкция языка, так что каждый пакет имеет имя и синтаксически четко определенную область.

[x]. P2 Описание каждого пакета содержит ряд объявлений связанных с ним элементов, таких как подпрограммы и переменные, которые в дальнейшем будут называться компонентами (features) пакета.

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

[x]. P4 В компилируемом языке (таком, который может быть использован для реализации, а не только для спецификации и проектирования) поддерживается независимая компиляция пакетов.

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

package INTEGER_TABLE_HANDLING feature

type INTBINTREE is

record

-- Описание представления двоичного дерева, например:

info: INTEGER

left, right: INTBINTREE

end

new: INTBINTREE is

-- Возвращение нового инициализированного INTBINTREE.

do ... end

has (t: INTBINTREE; x: INTEGER): BOOLEAN is

-- Содержится ли x в t?

do ... Реализация операции поиска ... end

put (t: INTBINTREE; x: INTEGER) is

-- Включить x в t.

do ... end

remove (t: INTBINTREE; x: INTEGER) is

-- Удалить x из t.

do ... end

end -- пакета INTEGER_TABLE_HANDLING

Этот пакет содержит объявление типа (INTBINTREE), и ряда подпрограмм, представляющих операции над объектами этого типа. В данном примере не потребовалось описания переменных пакета (хотя в подпрограммах могут иметься локальные переменные).

Пакеты-клиенты теперь могут работать с таблицами, используя различные методы из INTEGER_TABLE_HANDLING. Введем синтаксическое соглашение, позволяющее клиенту пользоваться методом f из пакета, для чего позаимствуем нотацию из языка CLU: P$f. В нашем примере типичные фрагменты программного текста клиента могут иметь вид:

-- Вспомогательные описания:

x: INTEGER; b: BOOLEAN

-- Описание t типа, определенного в INTEGER_TABLE_HANDLING:

t: INTEGER_TABLE_HANDLING$INTBINTREE

-- Инициализация t новой таблицей, создаваемой функцией new пакета:

t := INTEGER_TABLE_HANDLING$new

-- Включение x в таблицу, используя процедуру put пакета:

INTEGER_TABLE_HANDLING$put (t, x)

-- Присваивание True или False переменной b,

-- для поиска используется функция has пакета:

b := INTEGER_TABLE_HANDLING$has (t, x)

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

with INTEGER_TABLE_HANDLING then

... Здесь has означает INTEGER_TABLE_HANDLING$has, и т.д. ... end

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

Механизм пакетов обеспечивает скрытие информации, ограничивая права клиентов на доступ к компонентам. Показанный выше клиент был в состоянии объявить одну из своих собственных переменных, используя тип INTBINTREE, взятый от своего поставщика, и вызывать подпрограммы, описанные этим поставщиком. Но он не имеет доступа ни к внутреннему описанию этого типа (к структуре record, определяющей реализацию таблиц), ни к телу подпрограмм (здесь это операторы do). Кроме того, можно скрыть от клиентов некоторые компоненты пакета (переменные, типы, подпрограммы), делая их используемыми только в тексте пакета.

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

Пакеты: оценка

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

[x]. Автор модуля-поставщика может хранить в одном месте и совместно компилировать все элементы, относящиеся к некоторому заданному понятию. Это облегчает отладку и изменения. В отличие от этого, при использовании отдельных самостоятельных подпрограмм всегда есть опасность забыть произвести обновление некоторых подпрограмм при изменениях проекта или реализации; например, можно обновить new, put и has, но забыть обновить remove.

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

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

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

Но даже со стороны клиентов ситуация остается не вполне приемлемой. Каждое использование таблицы клиентом требует упомянутого выше объявления вида:

t: INTEGER_TABLE_HANDLING$INTBINTREE

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

Перегрузка и универсальность

Два технических приема - перегрузка (overloading) и универсальность (genericity) предлагают свои решения, направленные на достижение большей гибкости описанных выше механизмов. Рассмотрим, что же они могут дать.

Синтаксическая перегрузка

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

Для этого обсуждения более существенной является перегрузка подпрограмм, частным случаем которой является перегрузка операторов, которая позволяет использовать одинаковые имена для нескольких подпрограмм. Такая возможность почти всегда имеет место для арифметических операторов: одна и та же запись, a +b, означает различные виды сложения, в зависимости от типов a и b (целые, вещественные с обычной точностью, вещественные с удвоенной точностью). Начиная с языка Algol 68, в котором допускалась перегрузка основных операторов, некоторые языки программирования распространили возможность перегрузки на операции, определяемые пользователем, и на обычные подпрограммы.

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

square (x: INTEGER): INTEGER is do ... end

square (x: REAL): REAL is do ... end

square (x: DOUBLE): DOUBLE is do ... end

square (x: COMPLEX): COMPLEX is do ... end

Тогда при вызове square (y) тип аргумента y определит, какой вариант подпрограммы имелся в виду.

Подобным же образом, пакет может описывать набор функций поиска одинакового вида:

has (t: "SOME_TABLE_TYPE"; x: ELEMENT) is do ... end

Каждая из них задает свою реализацию и отличается фактическим типом, используемым вместо "SOME_TABLE_TYPE". Тип первого фактического аргумента, в любом клиентском вызове has, позволяет определить, какая из подпрограмм имелась в виду.

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

Роль перегрузки

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

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

has (t, x)

то необходимо будет объявить t, а следовательно (даже если скрытие информации освобождает вас от заботы о деталях каждого варианта алгоритма поиска) нужно точно знать, каков вид таблицы t! Единственным достоинством перегрузки является то, что во всех случаях можно пользоваться одним и тем же именем. Без перегрузки в каждой реализации потребуется другое имя, например

has_binary_tree (t, x)

has_hash (t, x)

has_linked (t, x)

Но является ли таки достоинством возможность избежать использования различных имен? Наверное нет. Основным правилом создания ПО, объектно оно или нет, является принцип честности (non-deception): различия в семантике должны отражаться в различиях текстов программ. Это позволяет существенно улучшить понятность ПО и минимизировать опасность возникновения ошибок. Если подпрограммы has являются различными, то использование для них одинакового имени может вводить в заблуждение - при чтении текста программы возникает предположение, что это одинаковые подпрограммы. Лучше предложить клиенту немного более многословный текст (как в случае введенных выше индивидуальных имен) и устранить какую-либо опасность путаницы.

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

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

p1 := new_point (u, v)

Точку можно задать: декартовыми координатами x и y; или полярными координатами r и q (расстоянием от начала координат и углом, отсчитываемым от горизонтальной оси). Но если перегрузить функцию new_point, то возникнет затруднение, связанное с тем, что оба варианта имеют одинаковую сигнатуру:

new_point (p, q: REAL): POINT

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

Семантическая перегрузка (предварительное представление)

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

Смысл такого запроса примерно таков:

Дорогой Компьютер (Hardware-Software Machine):

Разберитесь, пожалуйста, что такое t; я знаю, что это должна быть таблица, но не знаю, какую реализацию этой таблицы выбрал ее создатель - и, откровенно говоря, лучше, если я останусь в неведении об этом. Как-никак, я занимаюсь не организацией ведения таблиц, а банковскими инвестициями [или компиляцией, или автоматизированным проектированием и т.д.]. Начальник над таблицами здесь кто-то другой. Так что разберитесь в этом сами и, когда получите ответ, поищите подходящий алгоритм для 'has', соответствующий этому конкретному виду таблицы. Затем используйте найденный алгоритм, чтобы установить, содержится ли 'x' в 't', и сообщите мне результат. Я с нетерпением ожидаю вашего ответа.

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

Примите мои дружеские пожелания,

Искренне Ваш разработчик приложений.

В отличие от синтаксической перегрузки, такая семантическая перегрузка является прямым ответом на требование Независимости Представлений. Все еще остается подозрение о нарушении принципа честности (non-deception), и ответом будет использование утверждений (assertions), задающих общую семантику подпрограммы, имеющей много различных вариантов (например, общие свойства, характеризующие has при всевозможных реализациях таблицы).

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

Универсальность (genericity)

Универсальность - это механизм определения параметризованных шаблонов модулей (module patterns), параметры которых представляют собой типы. Это средство является прямым ответом на требование Изменчивости Типов. Оно устраняет необходимость использования многих модулей, таких как:

INTEGER_TABLE_HANDLING

ELECTRON_TABLE_HANDLING

ACCOUNT_TABLE_HANDLING

Вместо этого разрешается написать единственный шаблон модуля в виде:

TABLE_HANDLING [G]

Имя G, представляющее произвольный тип, и называется формальным родовым параметром (formal generic parameter). (Позже мы можем встретиться с необходимостью иметь два или более родовых параметров, но сейчас ограничимся одним.)

Такой параметризованный шаблон называется универсальным модулем (generic module), хотя это еще не настоящий модуль, а лишь общая схема - шаблон многих возможных модулей. Для получения фактического модуля из шаблона, следует задать некоторый тип, называемый фактическим родовым параметром. Модули, получаемые из шаблона заменой формального параметра G на фактический, записываются, например, в виде:

TABLE_HANDLING [INTEGER]

TABLE_HANDLING [ELECTRON]

TABLE_HANDLING [ACCOUNT]

Типы INTEGER, ELECTRON и ACCOUNT использованы, соответственно, в качестве фактических родовых параметров. Такой процесс получения фактического модуля из универсального модуля (шаблона модуля) называется родовым порождением (generic derivation), а сам модуль будет называться "универсально порожденным" (generically derived.).

Два небольших замечания относительно терминологии. Во-первых, родовое порождение иногда называют родовой конкретизацией (generic instantiation), а порожденный модуль называют тогда родовым экземпляром (generic instance) Эта терминология может привести к недоразумениям в ОО-контексте, поскольку термин "экземпляр" применяется к объектам, созданные во время выполнения из соответствующих типов (или классов). Так что мы будем придерживаться термина "порождение".

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

Внутренне, описание унифицированного модуля TABLE_HANDLING будет напоминать приведенное выше описание INTEGER_TABLE_HANDLING, за исключением того, что для ссылки на тип элементов таблицы используется G вместо INTEGER. Например:

package TABLE_HANDLING [G] feature

type BINARY_TREE is

record

info: G

left, right: BINARY_TREE

end

has (t: BINARY_TREE; x: G): BOOLEAN

-- Содержится ли x в t?

do ... end

put (t: BINARY_TREE; x: G) is

-- Включить x в t.

do ... end

(и т.д.)

end -- пакета TABLE_HANDLING

В этом подходе некоторое замешательство вызывает то обстоятельство, что тип, объявленный BINARY_TREE, хотелось бы сделать универсальным и объявить его как BINARY_TREE [G]. Нет очевидного способа достижения этой возможности при "пакетном" подходе. Однако объектная технология объединит понятия модуля и типа, так что проблема будет решена автоматически. Мы убедимся в этом, когда узнаем, как интегрировать универсальность (genericity) в ОО-мир.

Интересно сопоставить определение универсальности с приведенным ранее определением перегрузки:

Роль универсальности

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

Как же универсальность способствует реализации целей этой лекции? В отличие от синтаксической перегрузки, универсальность дает реальный вклад в решение наших проблем, поскольку, как было отмечено выше, она обеспечивает выполнение одного из основных требований, Изменчивости Типов. И при изложении объектной технологии в лекциях 7-18 этого курса значительное внимание будет уделено универсальности.

Основные методы модульности: оценка

Мы получили два основных результата. Одним из них является идея создания единого синтаксического "жилища", такого как пакетная конструкция (package construct), для множества подпрограмм, все из которых работают с однородными объектами. Вторым результатом является универсальность, приводящая к более гибкой форме модуля.

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

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

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

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

[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], публикация которых была задержана на несколько лет. Мак-Илрой пропагандировал развитие промышленного производства компонентов ПО.

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

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

Когда мы беремся за написание компилятора, то начинаем с вопроса: "Какой механизм работы с таблицами будем создавать?". А следует задавать вопрос: "Какой механизм будем использовать?" ...

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

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

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

Специальный выпуск 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 Министерства обороны США восьмидесятых годов прошлого века был акцентирован на проблеме повторного использования, особенно на организационных аспектах этой проблемы, причем в качестве языка для компонентов ПО использовался язык Ada. Ряд статей по этим вопросам можно найти в трудах конференции STARS DoD-Industry 1985 г. [NSIA 1985].

Двумя наиболее известными книгами по "образцам (шаблонам) проектов" являются [Gamma 1995] и [Pree 1994].

Работа [Weiser 1987] является призывом к распространению ПО в виде исходных текстов. Однако в этой статье недооценивается необходимость абстракции; как было показано в этой лекции, при необходимости можно сохранить возможность доступа к исходному тексту, но применить его высокоуровневую форму в качестве документации по умолчанию для пользователей модуля. Из других соображений Ричард Сталлман (Richard Stallman), создатель Лиги Сторонников Свободы Программирования (League for Programming Freedom), утверждал, что представление в виде исходного текста всегда должно быть доступно; смотрите [Stallman 1992].

В работе [Cox 1992] описывается идея суперпоставки (superdistribution) Некоторая разновидность перегрузки имелась в языке Algol 68 [van Wijngaarden 1975]; в языках Ada (в котором это распространено на подпрограммы), C++ и Java, которые будут рассмотрены в последующих лекциях, этот механизм широко используется.

Универсальность или полиморфизм (genericity) появляется в языках Ada и CLU, и в ранней версии языка спецификаций Z [Abrial 1980]; в этой версии синтаксис Z близок к используемому для представления универсальности в этой книге. Язык LPG [Bert 1983], был явно предназначен для исследования универсальности. (Название этого языка является аббревиатурой из начальных букв "Language for Programming Generically".)

Работа, цитированная в начале этой лекции в качестве основной ссылки на табличный поиск, это [Knuth 1973]. Среди многих пособий по алгоритмам и структурам данных, которые освещают этот вопрос, стоит обратить внимание на [Aho 1974], [Aho 1983] или [M 1978].

Две книги автора данной книги содержат дальнейший анализ вопроса повторного использования. Книга Reusable Software [M 1994a], полностью посвященная этой теме, представляет принципы разработки и реализации для создания высококачественных библиотек, и полную спецификацию множества базисных библиотек. В книге Object Success [M 1995] обсуждаются организационные аспекты проблемы повторного использования, особенно те сферы деятельности, в которых должна прилагать усилия фирма, заинтересованная в повторном использовании, и области, в которых такие усилия будут, по-видимому, бесполезными (например, рекомендации повторного использования разработчикам приложений, или поощрение осуществления ими повторного использования). Смотрите также короткую статью на эту тему, [M 1996].

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

Продолжение:

Часть 1 4. Подходы к повторному использованию
Часть 2 Несколько слов об индексировании компонентов - 4. Подходы к повторному
Часть 3 Пакеты - 4. Подходы к повторному использованию