Чтение онлайн

на главную - закладки

Жанры

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

Мейер Бертран

Шрифт:

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

Поделиться:
Популярные книги

Камень. Книга восьмая

Минин Станислав
8. Камень
Фантастика:
фэнтези
боевая фантастика
7.00
рейтинг книги
Камень. Книга восьмая

Очкарик 2

Афанасьев Семен
2. Очкарик
Фантастика:
фэнтези
альтернативная история
5.00
рейтинг книги
Очкарик 2

Убивать чтобы жить 8

Бор Жорж
8. УЧЖ
Фантастика:
боевая фантастика
космическая фантастика
рпг
5.00
рейтинг книги
Убивать чтобы жить 8

Барон Дубов 6

Карелин Сергей Витальевич
6. Его Дубейшество
Фантастика:
юмористическое фэнтези
аниме
сказочная фантастика
фэнтези
5.00
рейтинг книги
Барон Дубов 6

Отверженный IX: Большой проигрыш

Опсокополос Алексис
9. Отверженный
Фантастика:
попаданцы
альтернативная история
аниме
5.00
рейтинг книги
Отверженный IX: Большой проигрыш

На границе империй. Том 8. Часть 2

INDIGO
13. Фортуна дама переменчивая
Фантастика:
космическая фантастика
попаданцы
5.00
рейтинг книги
На границе империй. Том 8. Часть 2

Тринадцатый XI

NikL
11. Видящий смерть
Фантастика:
попаданцы
аниме
фэнтези
фантастика: прочее
5.00
рейтинг книги
Тринадцатый XI

Доктор 5

Афанасьев Семён
5. Доктор
Фантастика:
фэнтези
альтернативная история
5.00
рейтинг книги
Доктор 5

Законы Рода. Том 10

Андрей Мельник
10. Граф Берестьев
Фантастика:
юмористическая фантастика
аниме
фэнтези
5.00
рейтинг книги
Законы Рода. Том 10

Эволюционер из трущоб. Том 6

Панарин Антон
6. Эволюционер из трущоб
Фантастика:
попаданцы
аниме
фэнтези
5.00
рейтинг книги
Эволюционер из трущоб. Том 6

Барон Дубов 3

Карелин Сергей Витальевич
3. Его Дубейшество
Фантастика:
юмористическое фэнтези
аниме
сказочная фантастика
фэнтези
5.00
рейтинг книги
Барон Дубов 3

Кодекс Охотника. Книга XV

Винокуров Юрий
15. Кодекс Охотника
Фантастика:
попаданцы
аниме
5.00
рейтинг книги
Кодекс Охотника. Книга XV

Идеальный мир для Лекаря 27

Сапфир Олег
27. Лекарь
Фантастика:
аниме
фэнтези
5.00
рейтинг книги
Идеальный мир для Лекаря 27

Ведунские хлопоты

Билик Дмитрий Александрович
5. Бедовый
Фантастика:
юмористическое фэнтези
городское фэнтези
мистика
5.00
рейтинг книги
Ведунские хлопоты