М. Фаулер, К. Скотт - UML Основы (1114905), страница 21
Текст из файла (страница 21)
Производные ассоциации и атрибуты Производные ассоциации и производные атрибуты могут быть получены, соответственно, из других ассоциаций и атрибутов на диаграм- 99 Производные ассоциации и атрибуты ме классов. Например, значение атрибута возраст для Личности можно определить, если известна дата рождения атой Личности. Каждая точка зрения предполагает свою собственную интерпретацию производных ассоциаций и атрибутов на диаграмме классов.
Наиболее важная особенность связана с точкой зрения спецификации. С атой точки зрения важно понимать, что производные ассоциации и атрибуты устанавливают лишь ограничения между значениями, а не определяют то, что вычисляется и хранится постоянно. На рис. 6.8 изображена некоторая иерархическая структура счетов с позиции спецификации.
В данной модели используется образец Композиция(см. Гамма и др., 1996). (баланс = сумма статейт Рис. 8.8. Производные ассоциации и атрибуты Отметим следующее: ° Объекты класса Статья связаны с Детальными Счетами. ° Баланс некоторого Счета вычисляется как сумма его Статей. ° Статьи Итогового Счета являются статьями его компонентов, кото- рые определяются рекурсивно. Поскольку на рис.
6.8 изображена модель уровня спецификации, она ничего не утверждает относительно того, содержат ли Счета поля для Глава б. Диаграммы классов: дополнительные понятия хранения данных баланса. Такие данные могут присутствовать в модели, однако они скрыты от клиентов класса Счет.
На рис. 6.9 показан пример производных элементов, которые задают ограничения для класса с именем Период Времени. Рис. о.9. Класс Период Времени Если это диаграмма уровня спецификации, то, хотя и предполагается, что начало и окончание являются хранимыми атрибутами, а продолжительность — вычисляемым атрибутом, реально программист может реализовать этот класс любым способом, лишь бы при этом обеспечивалось его внешнее поведение. Например, вполне возможно сделать хранимыми атрибуты начало и продолжительность, а атрибут окончаниее — вычисляемым. На диаграмме уровня реализации производные значения являются важными для специально выделенных полей, используемых в качестве кзш-памяти для повышения производительности.
Помечая эти поля и записывая производные значения в кзш, можно легко видеть, как используется кэш-память. Как правило, я закрепляю назначение таких полей с помощью слова «кзш» в их именах в коде (например, балансКэш). На концептуальных диаграммах я использую производные маркеры, для того чтобы они напоминали мне, где эти производные элементы существуют и что нужно согласовать этот факт с экспертами предметной области, Затем все должно быть согласовано с использованием этих элементов на соответствующих диаграммах уровня спецификации.
Интерфейсы и абстрактные классы Одно из наиболее важных свойств объектно-ориентированной разработки заключается в возможности изменения интерфейсов классов независимо от их реализации. Именно благодаря этому свойству объектная разработка является столь мощным средством. Однако очень немногие разработчики используют это свойство должным образом. Интерфейсы и абстрактные классы В языках программирования используется единственная объектная конструкция — класс, который включает как интерфейс, так и реализацию.
Если вы определяете подкласс, то он наследует и то, и другое, К сожалению, разработчики крайне редко используют интерфейс как отдельную конструкцию. Интерфейс в чистом виде, как, например, в языке дача, представляет собой класс без каких-либо деталей реализации и поэтому содержит только определения операций, но не тела методов и не поля. Часто интерфейсы определяются на основе абстрактных классов. Такие классы могут предполагать некоторую реализацию, но в большинстве случаев они используются в основном для определения интерфейса.
Дело заключается в том, что механизм подклассов или какой-либо другой механизм может обеспечить реализацию, однако клиенты никогда не должны видеть ее, а только интерфейс. Типичным примером подобной ситуации является текстовый редактор, изображенный на рис. 6.10.
Чтобы сделать редактор независимым от платформы, мы определяем независимый от платформы абстрактный класс Окно. Этот класс не содержит тел методов; он определяет только интерфейс для использования в текстовом редакторе, За- о Текстовый редактор Рис. 6.10. Окно как аостпрактный класс Глава б.
Диаграммы классов: дополнительные понятия висимые от платформы подклассы могут использоваться как производные элементы. Если вы определяете абстрактный класс или метод, то язык УМ1 требует выделять его имя курсивом. Можно также (или вместо курсива) использовать ограничение (аЬв$гасЦ (абстрактный). На бумаге я обычно использую это ограничение, поскольку не умею писать курсивом. Однако я предпочитаю изящество курсива, если пользуюсь инструментальным средством для построения диаграмм.
Тем не менее, механизм подклассов отнюдь не является единственно возможным средством определения интерфейса. В языке дача интерфейс определяется как самостоятельная конструкция, и компилятор проверяет, чтобы в секции реализации класса реализовывались все операции, определенные в секции интерфейса данного класса. На рис.
6.11 показаны классы ВходнойПоток, ВводДанных и ВходнойПотокДанных (опредвляемые в стандартном пакете 1аиало). При этом ВходнойПоток является абстрактным классом, а ВводДанных— интерфейсом. Зал рооНа Ввод Рис. б,11. Интерфейсы и абстрактный класс: пример на языке 3аиа Предположим, некоторому классу-клиенту, скажем ЗапросНаВвод, требуется воспользоваться функциональностью класса ВводДанных. Класс ВходнойПотокДанных реализует интерфейсы как класса Ввод- Данных, так и класса ВходнойПоток, являясь при этом подклассом последнего.
Связь между классами ВходнойПотокДанных и ВводДанных представляет собой отношение реализации. Реализация сознательно изображается аналогично обобщению; она указывает, что один из классов реализует поведение„специфицированное в другом классе. Допускается ситуация, когда секция реализации одного класса реализует другой класс; это означает, что реализующий класс должен согласовывать свой интерфейс, но вовсе не должен использовать наследование. В модели уровня спецификации отсутствует различие между реализацией и механизмом подтипов.
Ссылочные объекты и объектънзначения Связь между классами ЗапроеНаВвод и ВводДанных представляет собой отношение зависимости (беренс)енсу). В данной ситуации она показывает, что если изменится интерфейс класса ВводДанных, то класс ЗапросНаВвод также может измениться. Одна из целей разработки состоит в сведении к минимуму количества зависимостей, для того чтобы воздействие подобных изменений было минимальным. (Более подробно о зависимостях будет сказано в главе 7.) Альтернативная и более компактная нотация изображена на рис. 6.12. Здесь интерфейсы представлены в форме маленьких кружков (называемых часто леденцами на палочках), которые соединены е реализующими их классами, Интерфейс "4к — — ЗапросНзйвод сависяиспь Вк Рис.
6.12. Графическая нотация для интерфейсов При использовании обозначения, похожего на леденцы на палочках, не существует различия между реализацией интерфейса и механизмом подклассов для некоторого абстрактного класса. Хотя эта нотация и является более компактной, в этом случае нельзя увидеть ни операций интерфейса, ни каких-либо отношений обобщения между интерфейсами. Абстрактные классы и интерфейсы похожи, однако между ними существует различие. Как те, так и другие позволяют определить интерфейс и отложить его реализацию на более позднее время. Однако абстрактный класс позволяет дополнить реализацию некоторых методов, в то время как интерфейс вынуждает отложить определение всех методов.
Ссылочные объекты и объекты-значения Одно из наиболее общих свойств объектов заключается в том, что они обладают индивидуальностью (ЫепсНу). Это так, но все обстоит не столь просто, как может показаться. На практике индивидуальность важна для сеылочных объектов н не столь важна для объектов-значений. Ссылочные объекты (гетегепее оЪ)ее1э) — это такие объекты, как Клиент. В данном случае индивидуальность очень важна, поскольку в ре- 104 Глава 6.
Диаграммы классов: дополнительные понятия альном мире конкретному клиенту обычно должен соответствовать только один программный объект. Любой объект, обратившийся к объекту Клиент, может воспользоваться соответствующей ссылкой или указателем; в результате все объекты, обратившиеся к данному Клиенту, получат доступ к одному и тому же программному объекту. Аналогично изменения, вносимые в объект Клиент, становятся доступными всем пользователям этого объекта. Если у вас имеются две ссылки на объект Клиент и вы хотите установить их тождественность, то обычно сравниваете индивидуальность тех объектов, на которые указывают эти ссылки.
Создание копий объектов может быть запрещено, но даже если оно разрешено, к нему стараются прибегать как можно реже, возможно, только с целью архивирования или репликации в сети. Если все же копии созданы, то необходимо обеспечить синхронизацию вносимых в них изменений. Объекты-значения (ча)пе оЬ)ес1в) — это такие объекты, как Дата.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
