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

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

Рис. 14.12. Набросок структуры библиотеки таблиц

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

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

Тип - это множество объектов, характеризуемых (как мы знаем из теории АТД) определенными операциями. INTEGER описывают множество целых чисел с арифметическими операциями, POLYGON– это множество объектов с операциями vertices, perimeter и другими.

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

Что означает это отношение?

[x]. Если рассматривать значения каждого типа, то это отношение является просто отношением включения множеств: собаки образуют подмножество множества животных, экземпляры класса RECTANGLE образуют подмножество экземпляров класса POLYGON. (Это следует из определения "экземпляра" в начале этой лекции, заметим, что прямой экземпляр класса RECTANGLE не является прямым экземпляром класса POLYGON).

[x]. Если рассматривать операции, применимые к каждому типу, то сказать, что B есть A, означает, что каждая операция, применимая к A применима также и к экземплярам B. (Однако при переопределении B может создать свою собственную реализацию, которая для экземпляров B заменит реализацию, предоставленную A.)

Используя это отношение можно описывать схемы отношения "является", представляющие многие варианты типов, например, все варианты класса FIGURE. Каждая новая версия таких подпрограмм как rotate и display определяется в классе, задающем соответствующий вариант типа. В случае таблиц, например, каждый класс на графе обеспечивает свою собственную реализацию операций search, insert, delete, разумеется, за исключением тех случаев, когда для него подходит реализация родителя.

Предостережение об использовании отношения "является" ("is a"). Начинающие - но я полагаю, ни один из читателей, добравшийся до этого места даже с минимумом внимания, - иногда путают наследование с отношением "экземпляр - образец", считая класс SAN_FRANCISCO наследником класса CITY. Это, как правило, ошибка: CITY– это класс, у которого может быть экземпляр, представляющий Сан Франциско. Чтобы избежать таких ошибок, достаточно помнить, что термин "является" означает не "x является одним из A" (например, "Сан Франциско является городом (CITY)), т.е. отношением между экземпляром и категорией, а выражает "всякий B является A" (например, "всякий ГОРОД является ГЕОГРАФИЧЕСКОЙ_ЕДИНИЦЕЙ"), т.е. отношение между двумя категориями, в программировании - двумя классами. Некоторые авторы предпочитают называть это отношение "является разновидностью" или "может действовать как" [Gore 1996]. Отчасти это дело вкуса (и частично этот предмет будет обсуждаться в лекции о методологии наследования), но поскольку мы уже знаем, как избежать тривиальной ошибки, то будем и далее использовать наиболее распространенное название "является", не забывая при этом, что оно относится к отношению между категориями.

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

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

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

Ne sutor ultra crepidam, (для сапожника ничего сверх сандалий) - это принцип разработки ПО: процедуре поворота не требуется знать полный список типов фигур. Ей должно хватать информации необходимой для выполнения своей работы: поворота некоторых видов фигур.

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

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