Блинков Ю.А., Месянжин В.В. (сост) Основы объектно-ориетнированного программирования. Саратовский Государственный университет, механико-математический факультет

Подождите немного. Документ загружается.

мостью Представлений.

Решение состоит в том, чтобы обеспечить автоматический выбор, осуществляемый системой ис-

полнения. Такова будет роль динамического связывания (dynamic binding), ключевой составляющей

ОО-подхода.

Факторизация Общего Поведения

Если требование Независимости Представлений отражает позицию клиента - игнорирование внут-

ренних деталей и вариантов реализации - то последнее требование отражает позицию разработ-

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

(commonality), которая может существовать в семействе или подсемействе реализаций.

Многообразие реализаций, имеющее место в некоторых проблемных областях, требует, как уже

отмечалось, решения, основанного на семействе модулей. Часто это семейство настолько велико, что

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

классификации может привести к трем обширным подсемействам:

• Таблицы, организуемые по некоторой схеме хеширования.

• Таблицы, организуемые как некоторая разновидность деревьев.

• Таблицы, организуемые последовательно.

Каждая из этих категорий охватывает много вариантов, но в большинстве случаев можно най-

ти существенную общность между этими вариантами. Рассмотрим, например, семейство последо-

вательных реализаций - таких, в которых элементы сохраняются и отыскиваются в порядке их

первоначального включения в таблицу.

Рис. 4.1: Некоторые возможные реализации таблицы

4.5 Традиционные модульные структуры

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

менчивости типов, группирования подпрограмм, изменчивости реализаций, независимости представ-

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

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

Подпрограммы

Классический подход к повторному использованию состоит в том, чтобы создавать библиотеки под-

программ. Здесь термин подпрограмма (routine) означает программный элемент, который может быть

вызван другими элементами для выполнения некоторого алгоритма, используя некоторые входные

данные, создавая некоторые выходные данные, и, возможно, модифицируя другие данные. Вызы-

вающий элемент передает свои входные данные (а иногда - выходные данные и модифицируемые

данные) в виде фактических аргументов (actual arguments) . Подпрограмма может также возвращать

выходные данные в виде результата; в этом случае она называется функцией.

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

сти, для численных расчетов, где применение отличных библиотек привело к первым сообщениям

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

декомпозицию, обеспечивает также метод нисходящего (сверху вниз) программирования. Подход,

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

определить множество (возможно - большое) отдельных задач, при наличии следующих ограниче-

ний:

• Каждая задача допускает простую спецификацию. Точнее, возможно охарактеризовать каждую

отдельную задачу небольшим набором входных и выходных параметров.

• Задачи четко отличаются одна от другой, поскольку подход, основанный на подпрограммах,

не позволяет воспользоваться возможной сколько-нибудь существенной их общностью - за

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

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

зующими их подпрограммами.

Пакеты

В семидесятые годы двадцатого века, в связи с развитием идей скрытия информации и абстракции

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

несколько языков проектирования и программирования, наиболее известные из них: CLU, Modula-

2 и Ada. В них предлагается сходная форма модуля, называемого в языке Ada пакетом, CLU -

кластером, Modula - модулем.

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

1. В соответствии с принципом Лингвистических Модульных Единиц,“пакет” это конструкция

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

2. Описание каждого пакета содержит ряд объявлений связанных с ним элементов, таких как

подпрограммы и переменные, которые в дальнейшем будут называться компонентами (features)

пакета.

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

компонентов другими пакетами. Другими словами, механизм пакетов поддерживает скрытие

информации.

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

для спецификации и проектирования) поддерживается независимая компиляция пакетов.

Благодаря свойству 3, пакеты можно рассматривать как абстрактные модули. Их главным вкла-

дом в программирование является свойство

2, удовлетворяющее требованию Группирования Подпро-

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

таблицы, включение, поиск и удаление элементов.

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

По сравнению с подпрограммами, механизм пакетов приводит к существенному совершенствованию

разбиения системы ПО на абстрактные модули. Собрать нужные компоненты“под одной крышей”

крайне полезно как для поставщиков, так и для клиентов:

• Автор модуля-поставщика может хранить в одном месте и совместно компилировать все эле-

менты, относящиеся к некоторому заданному понятию. Это облегчает отладку и изменения.

В отличие от этого, при использовании отдельных самостоятельных подпрограмм всегда есть

опасность забыть произвести обновление некоторых подпрограмм при изменениях проекта или

реализации; например, можно обновить new, put и has, но забыть обновить remove.

• Для авторов модулей-клиентов несомненно легче найти и использовать множество взаимосвя-

занных компонентов, если все они собраны в одном месте.

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

как рассмотренный здесь пример с таблицей, где в пакете собраны все операции, применимые к

конкретной структуре данных.

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

Как уже отмечалось, они отвечают требованию Группирования Подпрограмм, но не удовлетворяют

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

поведения -“вынесения за скобки” общих компонентов. Конечно, благодаря скрытию информации,

клиентам незачем интересоваться этим выбором. Но библиотека повторно используемых компонен-

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

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

вовсе не идентичных, модулей для заданной прикладной области, например, для работы с табли-

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

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

поставщиков.

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

Два технических приема - перегрузка (overloading) и универсальность (genericity) предлагают свои

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

что же они могут дать.

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

Перегрузка - это связывание с одним именем более одного содержания. Наиболее часто перегружа-

ются имена переменных: почти во всех языках программирования различные по смыслу переменные

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

языке Algol и подобных ему).

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

которой является перегрузка операторов, которая позволяет использовать одинаковые имена для

нескольких подпрограмм. Такая возможность почти всегда имеет место для арифметических опера-

торов: одна и та же запись, a + b, означает различные виды сложения, в зависимости от типов a

и b (целые, вещественные с обычной точностью, вещественные с удвоенной точностью). Начиная с

языка Algol 68, в котором допускалась перегрузка основных операторов, некоторые языки програм-

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

обычные подпрограммы.

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

Описанную форму перегрузки подпрограмм можно назвать синтаксической перегрузкой. В ОО-

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

щая целям Независимости Представлений. Динамическое связывание можно назвать семантической

перегрузкой.

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

• Для разработки ПО характерна повторяющаяся деятельность, включающая частое использова-

ние общих образцов (common patterns). Но имеются существенные вариации того, как исполь-

зуются и комбинируются эти образцы, так примитивные попытки работать с компонентами,

имеющимися в наличии, терпят неудачу.

• При практическом внедрении повторного использования возникают экономические, психоло-

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

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

компонентов. Более важными являются технические проблемы: общепринятые представления

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

• Основным затруднением при осуществлении повторного использования является необходи-

мость сочетать повторное использование с расширяемостью. Дилемма -“повторно использовать

или переделать” неприемлема. Хорошее решение должно обеспечить возможность сохранить

одни свойства повторно используемого модуля и адаптировать другие.

• Простые подходы к решению проблемы: повторное использование персонала, повторное исполь-

зование проектов, повторное использование исходного кода, библиотеки подпрограмм привели

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

вторного использования.

• Компонентом программы, пригодным для повторного использования, является абстрактный мо-

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

деленного интерфейса.

• Пакеты обеспечивают лучшую реализацию метода инкапсуляции, чем подпрограммы, посколь-

ку в них объединяются структура данных и связанные с ней операции.

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

• Перегрузка подпрограмм является синтаксическим средством, которое не решает важных про-

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

• Универсальность способствует повторному использованию, но решает лишь проблему измен-

чивости типов.

• Что же нам требуется: техника, помогающая поставщику учесть общность в группах взаимо-

связанных реализаций структур данных; и техника, избавляющая клиентов от необходимости

знать о том, какой вариант реализации выбран поставщиком.

Контрольные вопросы

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

уменьшает время разработки

снижает надежность приложения

повышает надежность приложения

позволяет отказаться от обработки исключительных ситуаций

2. Почему ПИК (Повторно Используемый Компонент) стоит использовать?

чаще всего, по экономическим причинам

для удовлетворения привычек пользователя

импортный товар всегда лучше

зачастую по причинам эффективности

3. Нужно ли создавать ПИК в процессе разработки системы?

только при наличии большого опыта и экономических предпосылок

всегда да, при наличии большого опыта

всегда нет, поскольку это удорожает и замедляет процесс ее создания

всегда да, поскольку это удешевляет и убыстряет процесс ее создания

4. Класс поведения - это?

абстрактный класс

отложенный класс

класс, описывающий поведение пользователей системы

класс, для которого задана частичная реализация, но некоторые особенности оставлены для

реализации различными потомками

5. Что представляет собой наиболее приемлемый образец, полезный для повторного использова-

ния?

спецификацию проблемы

сценарий решения проблемы

компонент ПО

описание алгоритма

6. Что можно повторно использовать?

программный код

текст

спецификации

персонал

7. Повторно использовать или переделывать