Видимость

Видимость (см. главу 9) принадлежащих пакету элементов можно контро­лировать точно так же, как видимость атрибутов и операций класса. По умолча­нию такие элементы являются открытыми, то есть видимы для всех элементов, содержащихся в любом пакете, импортирующем данный. Защищенные элементы видимы только для потомков, а закрытые вообще невидимы вне своего пакета. Например, на рис. 12.3 OrderForm (БланкЗаказа) - это открытая часть пакета Client(IOmeHT), a Order (Заказ) - закрытая. Любой пакет, импортирующий дан­ный, может «видеть» объект OrderForm, но не «видит» Order. При этом состав­ное имя для OrderForm будет Client: : OrderForm.

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

Аналогично классам для имен защищенных элементов используют символ # (диез), а для закрытых добавляют символ - (минус). Напомним, что защищенные элементы будут видны только для пакетов, наследующих данному (см. далее), а закрытые вообще не видны вне пакета, в котором объявлены.

Примечание Пакеты, связанные с некоторым пакетом отношениями зависимом со стереотипом friend (см. главу 10), могут «видеть» все элементы данного пакета, независимо от объявленной для них видимости

Импорт и экспорт

Предположим, у вас есть два класса одного уровня А и В, расположенных ря­дом друг с другом. А может «видеть» В и наоборот, то есть любой из них может зависеть от другого. Два таких класса составляют стандартную систему, и для них не надо задавать никаких пакетов.

Допустим теперь, что у вас имеется несколько сотен равноправных классов. Размер «паутины» отношений, которую вы можете соткать между ними, не под­дается воображению. Более того, столь огромную неорганизованную группу клас­сов просто невозможно воспринять в ее целостности. Описанная ситуация порож­дает реальную проблему больших систем: простой неограниченный доступ не позволяет осуществить масштабирование. В таких случаях для организации аб­стракций приходится применять пакеты.

Итак, допустим, что класс А расположен в одном пакете, а класс В - в другом, причем оба пакета равноправны. Допустим также, что как А, так и В объявлены открытыми частями в своих пакетах. Эта ситуация коренным образом отличается от двух предыдущих. Хотя оба класса объявлены открытыми, свободный доступ одного из них к другому невозможен, ибо границы пакетов непрозрачны. Однако если пакет, содержащий класс А, импортирует пакет-владелец класса В, то А смо­жет «видеть» В, хотя В по-прежнему не будет «видеть» А. Импорт дает элементам одного пакета односторонний доступ к элементам другого. На языке UML отноше­ния импорта моделируют как зависимости (см. главу 5), дополненные стереотипом import (о механизмах расширения UML см. главу 6). Упаковывая абстракции в се­мантически осмысленные блоки и контролируя доступ к ним с помощью импорта, вы можете управлять сложностью систем, насчитывающих множество абстракций.

Примечание Фактически в рассмотренной ситуации применяются два стерео­типа - import и access, - и оба они показывают, что исходный пакет имеет доступ к элементам целевого. Стереотип import до­бавляет содержимое целевого пакета в пространство имен исход­ного. Таким образом, возникает вероятность конфликта имен, ко­торой необходимо избегать, если вы хотите, чтобы модель была хорошо оформлена. Стереотип access не изменяет пространство имен цели, поэтому содержащиеся в исходном пакете имена необ­ходимо квалифицировать. Чаще используют стереотип import.

Открытые элементы пакета называются экспортируемыми. Так, на рис. 12.4 па­кет GUI экспортирует два класса - Windows и Form. Класс EventHandler явля­ется защищенной частью пакета. Довольно часто экспортируемыми элементами пакета оказываются интерфейсы (см. главу 11).

Экспортируемые элементы будут видны только тем пакетам, которые явно им­портируют данный. В примере на рис. 12.4 пакет Policies импортирует GUI. Taким образом, классы GUI: : Window и GUI: : Form будут из него видны. Но класс GUI: : EventHandler виден не будет, так как является защищенным. С другой

стороны, пакет Server не импортирует GUI, и потому элементы Server не име­ют права доступа к элементам GUI. По той же причине у GUI нет доступа к содер­жимому пакета Server.

Зависимости импорта и доступа не являются транзитивными. В данном при­мере пакет Client импортирует Policies, a Policies -GUI, однако это не зна­чит, что Client импортирует GUI. Таким образом, доступ из пакета Client к экс­портируемым частям пакета Policies разрешен, а к экспортируемым частям пакета GUI - нет. Чтобы получить такой доступ, надо явно указать, что Client импортирует GUI.

Примечание Элемент, видимый внутри пакета, будет видим также и внутри всех вложенных в него пакетов. Вообще, вложенные пакеты могут «видеть» все, что «видит» объемлющий их пакет.