О пакетах нужно знать то, что они соответствуют пространствам имён (namespace). Соответственно на них действуют те же самые правила. По большому счёту это логическая группировка типов. Под типами могут пониматься как классы (class) – типы определяемы пользователем, то есть программистом, так и другие, например структуры (struct), объединения (union), перечисления (enum), псевдонимы (typedef).

Здесь и далее анализ пространств имён рассматривается с точки зрения C++. Истинным Java программистам подобные основы вряд ли нужны, у них скорее будет передозировка проектированием, чем его недостаток. А вот C++ исповедует множественные парадигмы программирования, из-за этого часто его пользователи охватывают лишь одну из них и начинают хаить язык сверху донизу, якобы у них память утекает и тому подобное.

Данные диаграммы направлены прежде всего на обобщённое и объектно-оринетированное программирование, а там утечки памяти и прочие «недостатки» C++ это низкая культура использования данных парадигм и тотальное незнание шаблонов проектирования. Но речь сегодня не о них.

Предположим программист не использует пространства имён. С его точки зрения их нет, но на самом деле есть по крайне мере одно — глобальное. Обозначается оно двумя двоеточиями «::» и обычно опускается в самом начале предоставляя автоматический выбор в локальном пространстве имён. Причём при использовании глобальных имён всё же есть смысл прописывать «::» в начале, иногда из-за совпадений с локальными именами, иногда из-за смыслового подчёркивания.



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

Когда система обретает больший размах, начинают формироваться пространства имён. Или не начинают, так как программист может считать, что пространства имён сами по себе излишни, и непонятно зачем введены язык. Ему ведь и так хорошо, так спрашивается зачем усложнять себе жизнь.

Процесс формирования пространств имён может перерасти в программу разбитую на <<подсистем'ы>>. Классы в одном пространстве имён могут использовать классы из другого пространства имён, тогда возникают зависимости. В данном конкретном случае это значит, что одна <<подсистем'а>> будет работать без другой <<подсистем'ы>>, а наоборот нет.

Опять же <<система>> и <<подсистем'а>> это мой стереотип мышления, у другого программиста он может быть другим. Хотя в идеале для командной разработки нужно стремиться к тому, чтобы стереотипы совпадали.

Двигаясь дальше можно прийти к системам уровня предприятия (enterprise). Предположим существуют некие <<плагин'ы>>, а в них составные <<объект'ы>> формирующиеся несколькими классами. В <<плагин'е>> могут быть тысячи различных <<объект'ов>>. Их не стоит путать с объектами классов, так как в данном случае <<объект>> как и <<плагин>> являются стереотипами мышления.



Один проект <<объект'а>> по сложности может равняться проекту в глобальном пространстве имён приведённому в самом начале. То, чем гордится программист разрабатывающий маленькую утилиту может быть всего лишь одним из тысяч <<объект'ов>> одного из сотен <<плагин'ов>>. Стоит однако заметить, что на экране те же 32 проекта неких <<объект'ов> занимают не так уж и много места. Диаграммы пакетов довольно компактны, а пользы от них не мало, в том числе и в премоделировании, то есть моделировании до фазы кодирования.

В диаграммах пакетов могут применяться дополнительные значки, например, «+» или «-», чтобы указать должен ли класс быть доступен вне области видимости или нет, но это детали. Целью же данного обзора было лишь краткое рассмотрение диаграмм пакетов, как на витрине магазина, можно купить, а можно пройти мимо.