Локальная видимость

Локальная видимость (locally declared visibility) между объектами А и В существует в том случае, если объект В объявлен в качестве локальной перемен­ной в методе объекта А. Это относительно "временная" видимость, поскольку она существует только в контексте одного метода. Это третий по распространен­ности способ обеспечения видимости между объектами в объектно-ориентированных системах. Такая форма видимости между объектами достига­ется двумя следующими способами.

• Создается новый локальный экземпляр и присваивается в качестве значе­ния локальной переменной.

• Локальной переменной присваивается объект, возвращаемый другим методом.

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

В качестве примера второго варианта можно рассматривать метод enterItem класса Register (рис. 2.5).

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

Рисунок 2.5 – Локальная видимость

Глобальная видимость

Глобальная видимость (global visibility) между объектами А и В существует в том случае, когда объект В является глобальным по отношению к А. Это отно­сительно постоянная видимость, поскольку она поддерживается до тех пор, пока существуют объекты А и В. Это наиболее редкий способ обеспечения видимости между объектами в объектно-ориентированном программировании.

Один из способов достижения глобальной видимости состоит в присваива­нии экземпляра объекта глобальной переменной. Однако такой подход возможен не во всех языках (например, возможен в C++, но не в Java). Более предпочтительный способ состоит в использовании шаблона Singleton.

В языке UML существуют обозначения для иллюстрации различных типов ви­димости на диаграммах кооперации (рис. 2.6). Однако они являются необяза­тельными и зачастую не используются. Их применяют только в том случае, ко­гда требуется уточнить способ обеспечения видимости.

Рисунок 2.6 – Реализация различных способов обеспече­ния видимости

Вопрос 3. Модель проектирования: создание диаграммы классов

Хотя в ходе лабораторных работ диаграммы классов создаются после диаграмм взаимодейст­вия, на самом деле они зачастую разрабатываются параллельно. Имена многих классов, методов и типы отношений с помощью шаблонов распределения обя­занностей можно определить уже на начальной стадии проектирования, до по­строения диаграмм взаимодействия. Желательно выполнять проектирование следующим образом: сначала стоит построить схематичные диаграммы взаимо­действия, затем создать диаграммы классов, после чего детализировать диаграм­мы взаимодействия и т.д.

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

Диаграмма классов, представленная на рис. 3.1, иллюстрирует фрагмент про­граммного решения для классов Register и Sale.

Рисунок 3.1 – Пример диаграммы программных классов

Диаграмма классов (design class diagram) иллюстрирует спецификации про­граммных классов и интерфейсов (например, интерфейсов Java, С# и т.д.) в приложении. Обычно на такую диаграмму выносится следующая информация:

• Классы, ассоциации и атрибуты;

• Интерфейсы со своими операциями и константами;

• Методы;

• Информация о типах атрибутов;

• Способы навигации;

• Зависимости.

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

В RUP не определен отдельный артефакт под названием "диаграмма классов про­ектирования". Там определена лишь модель проектирования, которая может вклю­чать несколько типов диаграмм, в том числе диаграммы классов, взаимодействия и пакетов. Диаграммы классов из модели проектирования RUP иллюстрируют "классы проектирования" в терминах RUP. Поэтому зачастую диаграммы классов из модели проектирования называют просто диаграммами классов проектирования.