Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 78

Интерфейсы с множеством реализаций в классах+коллекциях Java426Глава 19. Интерфейсы и компоненты19.5. Сравнение реализации интерфейсаи наследованияРеализация интерфейса – «реализует определяемый им контракт».Теперь стоит обсудить, в чем разница между реализацией интерфейсаи наследованием. Семантика реализации интерфейса – «реализует определенный контракт», а семантика наследования – «является». Принцип замещаемости применим как к наследованию, так и к реализацииинтерфейса.

Таким образом, оба типа отношений могут формироватьполиморфизм.Семантика наследования – «является».Чтобы проиллюстрировать разницу между реализацией интерфейсаи наследованием, мы предлагаем альтернативное решение для системы управления библиотекой на основании наследования (рис. 19.7).Оно кажется вполне приемлемым и в некотором отношении даже более простым, но здесь есть некоторые проблемы.Прежде всего обсудим, почему эта основанная на наследовании модельне совсем подходит. Здесь очень четко определяется, что объекты Bookи CD имеют тип BorrowableItem. Но разве этой способности Book и CD бытьвыданными на время достаточно для описания их типа? Наверное, ееможно было бы рассматривать как один из аспектов их поведения, который оказался бы общим в контексте библиотечной системы.

Семантически правильнее рассматривать BorrowableItem как отдельную роль,которую Book и CD играют в Library, а не как общий надтип.Чтобы конкретизировать недостаток модели, изображенной нарис. 19.7, добавим в систему Library класс Journal (журнал). Journal – этопериодическое издание, такое как «Nature» (Природа), не выдаваемоеLibrary10..*BorrowableItemBookCDРис.

19.7. Модель, основанная на наследовании, имеет недостаток42719.5. Сравнение реализации интерфейса и наследования1Library10..*0..*BorrowableItemBookNonBorrowableItemCDJournalРис. 19.8. Модель Library с двумя списками объектовна время. В результате получается основанная на наследовании модель, представленная на рис. 19.8.Обратите внимание, что теперь Library должен обслуживать два спискаобъектов – те, которые могут, и те, которые не могут выдаваться на время. Такое решение работоспособно, но не очень изящно, посколькув нем смешиваются два очень разных понятия системы Library:• хранящиеся объекты;• объекты, выдаваемые на время.Эту модель можно несколько усовершенствовать, введя дополнительный уровень иерархии наследования, как показано на рис.

19.9. Использование класса LibraryItem (библиотечная позиция) избавляетот одного из отношений композиции. Такое решение в принципе подLibrary10..*LibraryItemBorrowableItemBookNonBorrowableItemCDJournalРис. 19.9. Усовершенствованная модель Library428Глава 19. Интерфейсы и компонентыходит, поскольку в нем используется только наследование. Протокол«выдаваемый на время» вынесен в отдельный уровень иерархии наследования. Это обычное решение проблемы такого рода.Модель, использующая и интерфейсы, и наследование, обеспечиваетболее элегантное решение (рис. 19.10).Основанное на интерфейсах решение имеет следующие преимущества:•каждая позиция в Library является LibraryItem;•понятие «возможность выдачи на время» вынесена в отдельный интерфейс, Borrowable, который может применяться к классам LibraryItem в случае необходимости;•сокращается число классов – пять классов и один интерфейс в противоположность семи классам в другом решении;•меньше отношений композиции – одно в противоположность двумв другом решении;•более простая, состоящая всего из двух уровней, иерархия наследования;•меньше отношений наследования – три в противоположность пятив другом решении.В общем, основанное на интерфейсе решение проще и обладает лучшейсемантикой.

Такие характеристики, как catalogNumber (номер каталога), которые есть у всех LibraryItem, были вынесены в базовый класс,чтобы обеспечить возможность их наследования. А протокол «возможность выдачи на время» определен отдельно в интерфейсе Borrowable.Library10..*LibraryItemBookCDJournalBorrowableРис. 19.10. Модель Library, использующая и интерфейсы, и наследование42919.5. Сравнение реализации интерфейса и наследованияЧтобы проиллюстрировать гибкость интерфейсов, давайте пойдемв этом примере на шаг вперед. Предположим, что необходимо экспортировать данные классов Book и Journal (но не CD) в XMLфайлы. Прикладные драйверы в этом случае должны обеспечивать возможность обменаинформацией с другими библиотеками и представления каталога печатных материалов в Веб.

Было спроектировано следующее решение:• для осуществления экспорта в XML введен класс XMLExporter;• введен интерфейс XMLExportable, определяющий протокол для работы с XMLExporter, который должен быть у каждой экспортируемойпозиции.Имеются следующие нефункциональные требования:• языком реализации должен быть Java;• для обработки XML должна использоваться библиотека JDOM(JDOM – простая, но мощная библиотека Java для работы с XMLдокументами; см. www.jdom.org).Протокол XMLExportable – это всего лишь одна операция getElement(), возвращающая представление экспортируемого элемента в виде классаElement, описанного в библиотеке JDOM. Класс XMLExporter используетJDOM для записи объектов Element в XMLфайл.Полностью решение представлено на рис. 19.11.Library10..*LibraryItemXMLExportableBookCDXMLExportableJournalBorrowableXMLExporter«interface»XMLExportablewriteXMLDocument( filename:String, root:Element, elements:XMLExportable[ ] )getElement():ElementРис.

19.11. Усовершенствованная модель Library с возможностью экспортаданных в XML+файлы430Глава 19. Интерфейсы и компонентыИнтерфейсы используются для описания общих протоколов классов,которые обычно не связываются через наследование.В данном решении удалось разделить вопросы хранения (отношениекомпозиции), выдачи на время (Borrowable) и экспортируемости (XMLExportable). Интерфейсы использовались для определения общих протоколов классов, которые не должны быть связаны через наследование.19.6.

ПортыПорт группирует семантически связанный набор предоставляемыхи требуемых интерфейсов. Он указывает на конкретную точку взаимодействия классификатора и его окружения.Порт группирует семантически связанный набор предоставляемых и требуемых интерфейсов.Пример на рис. 19.12 иллюстрирует нотацию порта. Здесь показанкласс Book, имеющий порт presentation (представление). Этот порт состоит из требуемого интерфейса DisplayMedium (устройство отображения) и предоставляемого интерфейса Display (отображение). Имя портаявляется необязательным. На рисунке показано два варианта нотациипорта: слева – обычная, а справа – более краткий альтернативный вариант.

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

Например, на рис. 19.13показан класс Viewer (средство просмотра), соединяющийся с портомpresentation класса Book. Чтобы обеспечить возможность соединенияпортов, их предоставляемый и требуемый интерфейсы должны совпадать. Использование портов, очевидно, обеспечивает намного болееDisplayMediumBookBookDisplayMediumпортpresentationpresentation:DisplayDisplayимя портаРис. 19.12. Два варианта нотации портатип порта19.7. Интерфейсы и компонентноBориентированная разработкаViewer431Bookviewpresentation:DisplayРис. 19.13.

Соединение портовкраткое представление, чем отображение всех предоставляемых и требуемых интерфейсов, но может и усложнять чтение диаграмм.У портов может быть видимость. Когда порт изображается перекрывающим границу классификатора, он является открытым. Это означает,что предоставляемый и требуемый интерфейсы открытые (public). Если прямоугольник порта находится внутри границы классификатора(как показано на рис. 19.14), видимость порта принимает два значения: или защищенный (protected) (по умолчанию), или закрытый (private). Фактическая видимость графически не отображается, но записывается в спецификации порта.AaProtectedPortРис. 19.14. Защищенный портУ порта может быть кратность.

Ее указывают в квадратных скобках после имени порта и его типа (например, presentation:Display[1]). Кратностьуказывает на количество экземпляров порта, которые будут иметь экземпляры классификатора.19.7. Интерфейсы и компонентноориентированная разработкаКомпонентноориентированная разработка заключается в построениипрограммного обеспечения из подключаемых частей.Интерфейсы – ключ к компонентноориентированной разработке (componentbased development, CBD). Она заключается в построении программного обеспечения из подключаемых частей. Если требуется создать гибкое, ориентированное на компоненты программное обеспечение, для которого по желанию можно подключать новые реализации,при проектировании должны использоваться интерфейсы.