Как разобраться в интерфейсе

Создав новый интерфейс, вы первым делом смотрите на набор операций, определяющих сервис класса или компонента. Если заглянуть поглубже, то станут видны полные сигнатуры этих операций, а также их специальные свойства (см главу 9): видимость, область действия и семантика одновременности (см. главу 23).

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

На языке UML вы можете связать с интерфейсом значительно больше инфор­мации, чтобы сделать его понятнее. Прежде всего, можно описать предусловия и постусловия для каждой операции, а также инварианты для класса или компо­нента в целом (см. главу 9). Таким образом, клиент сумеет понять, что и как дела­ет интерфейс, без необходимости изучать его реализацию. Если вы хотите фор­мально описать семантику, воспользуйтесь языком OCL (см. главу 6). Кроме того, к интерфейсу можно присоединить автомат (см. главу 21) и использовать его для специфицирования корректной частичной упорядоченности операций. Наконец, с ним допустимо связать кооперации (см. главу 27), описывающие ожидаемое поведение интерфейса с помощью последовательности диаграмм взаимодействия.

Типы и роли

Класс может реализовывать несколько интерфейсов. Любой экземпляр данно­го класса должен поддерживать их все, так как интерфейс определяет условия контракта, и все соответствующие ему абстракции обязаны соблюдать эти усло­вия. Тем не менее в конкретном контексте экземпляр может предоставлять только те интерфейсы, которые соответствуют ситуации. Это означает, что каждый ин­терфейс определяет роль, которую играет объект. Роль, таким образом, - это име­нованное поведение некоторой сущности в конкретном контексте, или, иными словами, - лицо, которым абстракция обращена к миру. (Роли принимают учас­тие также в кооперациях - см. главу 27.)

Рассмотрим, например, экземпляр класса Человек. В зависимости от контек­ста экземпляр этого класса может играть роль Матери, Налогоплательщика, Ра­ботника, Покупателя, Менеджера, Летчика, Певца и т.д. Следовательно, объект предъявляет миру ту или иную «личину», и взаимодействующие с ним клиенты ожидают от него соответствующего поведения. Например, экземпляр класса Че­ловек в роли Менеджера обладает не таким набором свойств, какой был бы у него в роли Матери.

На языке UML роль, которую одна абстракция играет по отношению к другой, Можно описать, дополнив соответствующую концевую точку ассоциации (см. гла­вы 5 и 10) именем интерфейса. Например, на рис. 11.5 показан интерфейс Работник, определение которого включает три операции. Между классами Человек и Компания существует ассоциация, в контексте которой Человек играет роль е, относящуюся к типу Работник. В другой ассоциации этот класс может быть «обращен к миру иным лицом». При наличии явного типа роль, которую играет Человек, - это не просто слово, понятное для читателя, изучающего диаграмму. В UML Это означает, что класс Человек играет для класса Компания роль Работника,

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

Диаграмма классов (см. главу 8), подобная приведенной выше, полезна для мо­делирования статического связывания абстракции с ее интерфейсом. Динамичес­кое связывание абстракции с интерфейсом моделируют с помощью стереотипа become (см. главу 13) на диаграмме взаимодействия, отражающей смену ролей объекта.

Для формального моделирования семантики абстракции и ее соответствия не­которому интерфейсу применяется предопределенный стереотип type. Это стерео­тип класса; с его помощью определяют область действия объектов совместно с опе­рациями (но не методами), применимыми к объектам этого типа. Концепция типа тесно связана с концепцией интерфейса, только описание типа может содержать атрибуты, а описание интерфейса - нет. Если надо показать, что некоторая абстрак­ция статически типизирована, используйте стереотип implementationClass, который специфицирует класс со статически типизированными экземплярами (класс Человек из рассмотренного примера не относится к их числу) и определя­ет физическую структуру данных и методы объекта так, как это делается в тради­ционных языках программирования.

Примечание В большинстве случаев понятия «тип» и «интерфейс» взаимоза­меняемы.