А. Техники и обозначения

A.1.1 Тип и класс

Отправной точкой является понятие типа, представленное прямоугольником. Очень важно, что я использую слово тип, а не класс. Очень важно понимать разницу между ними. Тип описывает интерфейс класса. Тип может быть реализован многими классами, а класс может реализовать множество типов. Один тип может быть реализован многими классами с различными языками, компромиссами в производительности и так далее. Один класс также может реализовывать множество типов, особенно если речь идет о подтипах. Различие между типом и классом очень важно для ряда методов проектирования, основанных на делегировании, как это обсуждается в книге «банды четырех» [3]. Эти два термина часто путают, потому что большинство языков не делают явного различия. Действительно, большинство методов анализа и проектирования не делают явного различия.

Я считаю полезным рассматривать построение диаграмм типов (это различие может быть применимо и к другим методам, но наиболее ярко оно проявляется в отношении структурных моделей) с трех точек зрения: концептуальной, спецификационной и реализационной [4]. Концептуальные модели моделируют то, как люди думают о мире. Это полностью мысленные картины, которые игнорируют любые технологические вопросы. Концептуальные модели могут различаться в зависимости от того, представляют ли они реальный мир или то, что мы знаем о нем. В качестве примера можно привести человека и дату его рождения. В реальном мире все люди имеют дату рождения, поэтому разумно моделировать дату рождения как обязательный атрибут человека. Однако мы можем знать человека, не зная его даты рождения. Таким образом, для многих областей дата рождения может быть необязательной в концептуальной модели, отражающей то, что мы знаем о мире. Это различие может быть очень важным для исторической информации. Модель, отражающая структуру мира в том виде, в каком она есть, часто может быть лучше всего нарисована как моментальный снимок момента времени. Однако если она представляет то, что мы знаем, то часто должна отражать и наши воспоминания. Модели, представленные в этой книге, рассматриваются с точки зрения создания модели того, что мы знаем о мире, поскольку именно такая перспектива наиболее полезна в информационных системах.

Модели спецификаций — это модели, которые могут быть использованы для определения интерфейса программных компонентов в системе. Модели спецификаций могут быть неявными или явными. Примером явной модели спецификации может служить заголовочный файл C++, в котором подробно описано, какие операции существуют, их параметры и возвращаемые типы. Неявные модели спецификации должны быть объединены с некоторыми соглашениями, которые показывают, как они разрешаются в явный интерфейс. Например, атрибут birthdate в неявной спецификационной модели разрешается в операции birthdate и birthdate: aDate для Smalltalk, и в операции Date getBirthdate() const и void setBirthDate(Date) для C++.

Неявные модели спецификаций могут быть ближе к концептуальным моделям, чем явные модели, и они также могут нести больше информации, чем многие явные интерфейсы. Интерфейсы C++ и Smalltalk не содержат большого количества информации о правилах использования частей интерфейса. Eiffel, в котором есть утверждения, может быть более полной, но менее понятной, чем неявная модель, которая близко следует концептуальной модели.

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

Концептуальные модели и неявные модели спецификаций практически идентичны. Таким образом, диаграммы типов в этой книге можно считать как концептуальными моделями, так и неявными моделями спецификаций. Если между ними возникает различие, я указываю на него в тексте. Немногочисленные модели реализации в книге явно обозначены как таковые, но я использую ту же нотацию.

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

A.1.2 Ассоциации, атрибуты и агрегация

Ассоциации представляют собой отношения между экземплярами типов (человек работает в компании, у компании есть несколько офисов и так далее). Точная интерпретация ассоциаций зависит от того, являются ли они частью концептуальной, спецификационной или реализационной модели. Концептуальная интерпретация просто утверждает, что между объектами существует концептуальная связь. С точки зрения ответственности, они несут ответственность за знание друг о друге. Таким образом, ассоциация между заказом и клиентом интерпретируется как означающая, что заказ знает своего клиента и наоборот. В модели спецификации существуют операции для доступа к отношениям и их обновления; явная модель спецификации показывает операции и их имена на модели. Модель реализации интерпретирует ассоциацию как существование указателя или другой ссылки. Важно отметить, что в концептуальных и спецификационных моделях ассоциации не указывают на структуру данных. Таким образом, сохраняется инкапсуляция.

Мне нравится проводить различие между ассоциацией и сопоставлением. Сопоставление (mapping) — это направленная связь от одного типа к другому. Ассоциация содержит одно или два сопоставления. Однонаправленная ассоциация — это только одно сопоставление, и ее можно рассматривать как то же самое, что и сопоставление. Двунаправленная ассоциация содержит два сопоставления, которые, как говорят, являются инверсиями друг друга. Это не совсем то же самое, что обратные функции в математике. По сути, это означает, что если вы перейдете по сопоставлению и его инверсии, то получите коллекцию объектов, включающую тот, с которого вы начали. Таким образом, если клиент просматривает набор заказов, которые он сделал, каждый из этих заказов указывает обратно на этого клиента. Термин «источник» (или домен) указывает на тип, с которым оно сопоставляется, а термин «цель» (или диапазон) указывает на тип, с которым сопоставляется отображение. (Например, в связке «клиент — заказ» клиент является источником, а заказ — целью). Когда имя появляется вместе с ассоциацией, это имя одного из отображений. Вы можете определить, какое это отображение, по расположению имени в строке ассоциации: Если цель находится впереди, а источник — сзади, то имя находится слева.

Существуют некоторые разногласия по поводу ценности двунаправленных ассоциаций. Концептуально все отношения являются двунаправленными. Рассмотрим ассоциацию между человеком и датой его рождения. С концептуальной точки зрения имеет смысл сказать, что существует связь между датой и людьми, родившимися в эту дату. В спецификационной модели это не так. Если дать дате набор операций для всех вещей, которые на нее ссылаются, то интерфейс даты рождения раздуется до неоправданной степени. Другая проблема с двунаправленными ассоциациями заключается в том, что они увеличивают связь между типами. Это может затруднить повторное использование. Многие люди используют однонаправленные ассоциации, чтобы уменьшить зависимость между типами. Контраргумент заключается в том, что в информационных системах большая часть работы заключается в навигации по связям между типами. Когда эти связи в основном однонаправленные, найти дорогу становится сложнее. Аналогией может служить попытка сориентироваться в городе: Улицы с односторонним движением значительно усложняют задачу, даже если вы знаете город.

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

Ключевым аспектом ассоциаций является кардинальность (иногда называемая множественностью). Она определяет такие вещи, как количество компаний, в которых может работать человек, и количество детей у матери. Кардинальность — это характеристика отображения, а не ассоциации: Каждое отображение имеет свою собственную кардинальность. Существует множество символов для обозначения кардинальности; на рисунке A.1 показаны те, которые я использую в этой книге. Отображения, верхняя граница которых равна единице, называются однозначными, а c верхнeй границей больше единицы, называются многозначными. Предполагается, что многозначные отображения представляют собой множество, если не указано иное (короткое семантическое утверждение).

Рисунок A.1 Символы для обозначения кардинальности, используемые в этой книге.

В этой книге я рассматриваю атрибут как то же самое, что и однозначное отображение. Иногда я показываю атрибут внутри прямоугольника типа, иногда — вместе с ассоциацией. Разница заключается лишь в удобстве обозначений.

Некоторые методы используют отношения агрегирования, которые представляют собой отношения «часть/целое» (например, молоток состоит из головки и стержня). В этой книге я не очень часто использую агрегацию. Я не считаю эту концепцию очень полезной для доменных моделей, потому что большая часть ее семантики относится к любой ассоциации. Таким образом, она становится еще одним элементом обозначения, который нужно запомнить и о котором нужно спорить, а результат спора обычно не очень важен в любом случае. Однако я использую его в прикладном уровне (см. раздел 13.6).

Производные (или вычисляемые) ассоциации описывают, как ассоциации могут быть определены на основе других базовых ассоциаций (таким образом, дед — это ассоциация, определенная с помощью родительской ассоциации, за которой следует ассоциация отца). Производные отображения в концептуальной модели указывают, что отображение основано на других отображениях, присутствующих в модели. В спецификационной модели это указывает на то, что результат работы аксессора для производного отображения такой же, как и при использовании комбинации базовых отображений. Таким образом, производное отображение можно рассматривать как ограничение между производным и базовым отображениями. Пометка отображения как производного не имеет никакого значения для базовой структуры данных, кроме этого ограничения. Исполнитель может выбрать любую структуру данных, лишь бы у пользователя типа создавалось впечатление, что производное отображение является производным в соответствии с моделью. В модели реализации производные отображения указывают на разницу между хранимыми данными и методом над этими данными.

Существует множество других вариаций на тему ассоциаций. Я стараюсь максимально упростить ситуацию. Некоторые полезные вариации обсуждаются в главе 15 как шаблоны ассоциаций.

A.1.3 Обобщение

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

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

Наследование и подклассификация в ОО-языках — это подход к реализации, при котором подкласс наследует данные и операции суперкласса. У него много общего с подтипированием, но есть и важные различия. Подклассификация — это только один из способов реализации подтипизации (см. раздел 14.2). Подклассификация может использоваться и без подтипирования, но большинство авторов справедливо не одобряют такую практику. Новые языки и стандарты все чаще стараются подчеркнуть разницу между наследованием по интерфейсу (подтипирование) и наследованием по реализации (подклассификация).

Возникает два вопроса, касающихся отношений между объектом и типом. Во-первых, имеет ли объект один тип, который может наследоваться от супертипов (одиночная классификация), или у него несколько типов (множественная классификация)? Множественная классификация отличается от множественного наследования. При множественном наследовании тип может иметь множество супертипов, но каждый экземпляр относится к одному типу, который может иметь супертипы. Множественная классификация позволяет использовать несколько типов для объекта, не определяя конкретный тип для этой цели. В качестве подтипов клиента могут быть персональные, корпоративные и важные клиенты. Клиент может быть как личным, так и важным. С помощью множественной классификации мы можем присвоить объекту как личный, так и важный тип клиента (при этом клиент наследуется от них). Без множественной классификации мы должны явно определить тип важного личного клиента. Если существует много подтипов, то в итоге мы можем получить очень большое количество комбинаций, которыми трудно управлять.

Концептуально говоря, множественная классификация — это более естественный способ мышления. Однако большинство ОО-языков, и, конечно, основные C++ и Smalltalk, используют подход с одной классификацией. Многие методы также используют однократную классификацию. Компромисс заключается в выборе между концептуально более естественным подходом, который требует больше усилий при преобразовании в код, и более привязанным к реализации подходом, который легче преобразовать. Я предпочитаю более концептуальный подход и использую множественную классификацию в этой книге.

При использовании множественной классификации мы должны показать, какие комбинации являются допустимыми, сгруппировав подтипы в разделы, как показано на рисунке A.2. Типы в одном разделе являются непересекающимися; то есть ни один объект не может быть экземпляром более чем одного типа в одном разделе. Таким образом, невозможно, чтобы супертип был одновременно подтипом-1 и подтипом-2. Неполное разбиение указывает на то, что экземпляр супертипа не обязательно должен быть экземпляром подтипа в пределах этого разбиения. Полное разбиение означает, что каждый экземпляр супертипа должен быть также экземпляром подтипа в пределах этого разбиения.

Второй вопрос — может ли объект изменить свой тип. Например, когда банковский счет переполнен, он существенно меняет свое поведение, переопределяя несколько операций (снятие, закрытие). Динамическая классификация позволяет объектам менять тип в рамках структуры подтипов, в то время как статическая классификация этого не делает. Опять же, основные языки ОО и большинство методов ОО являются статическими, и здесь действуют те же компромиссы, что и при классификации на один/множество. В этой книге используется более концептуальный подход к динамической классификации.

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

Экземпляр супертипа может быть подтипом-1 и подтипом-4, но не подтипом-1 и подтипом-2 одновременно.

Рисунок A.2 Обобщающие обозначения.

Использование динамической классификации выявляет тонкое различие между концептуальной и реализационной моделями. В концептуальной модели все подтипы считаются динамическими, если это явно не отрицается коротким семантическим утверждением [immutable]. Это отражает не только изменения, которые могут происходить в мире, но и наши меняющиеся знания о них. Для некоторых предприятий может быть верно, что личный клиент не может превратиться в корпоративного. Также может оказаться, что клиент, которого мы считали личным, на самом деле является корпоративным. Здесь наши знания о мире подразумевают динамическую классификацию, даже если сам мир статичен. Информационные системы обычно строятся на основе наших знаний о мире, поэтому концептуально подтипизация является динамической.

Однако нельзя игнорировать дополнительную сложность обработки динамической классификации. Поэтому концептуально динамические подтипы часто объявляются статическими в модели спецификации. Это фактически означает, что, хотя мы знаем, что классификация может измениться, это происходит достаточно редко, чтобы мы не хотели прилагать дополнительные усилия (и затраты) для ее поддержки. Если это все же произойдет, пользователям придется разбираться с этим путем копирования и замены. Для многих ситуаций дина-мизм достаточно редок, чтобы такой подход был оправдан. Гибкость в долгосрочной перспективе можно сохранить, обеспечив одинаковый интерфейс аксессора в любом случае (см. раздел 14.2.6).

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

Если вы используете метод, в котором не применяется множественная динамическая классификация, то вам нужно будет преобразовать модели, используя шаблоны, разработанные в разделе 14.2.

A.1.4 Правила и семантические утверждения

Ассоциации и подтипы позволяют нам сказать о типах многое, но не все. У меня может быть объект полиса страхования жизни с отображениями для страхователя и бенефициаров. Я могу использовать ограничения кардинальности, чтобы отразить такие утверждения, как то, что есть только один страхователь, но может быть много бенефициаров; однако эти ограничения не позволяют нам сказать, что страхователь не должен быть бенефициаром. Для этого нам нужно более гибкое ограничение. Ограничение — это логическое выражение о типе, которое всегда должно быть истинным. Ограничения часто отсутствуют в ОО-методах, хотя они уже давно присутствуют в Eiffel (где они называются инвариантами).

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

Рисунок A.3. Нотация для семантических утверждений.

Не все можно выразить в коротком смысловом высказывании. Когда требуется больше места, я использую длинное смысловое высказывание, которое содержит больше текста в ящике с собачьими ушками. Длинное семантическое высказывание имеет заголовок, указывающий на то, что оно описывает. Эти заголовки перечислены в таблице А.2.

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

A.1.5 Основные типы

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

В объектных системах мы можем легко определить новые типы, которые обладают многими из тех же возможностей, что и встроенные типы. Классический пример из Smalltalk — дробь. В Smalltalk дробь работает так же, как и любое другое число. Если выполнить вычисление 1/3 в Smalltalk, ответом будет дробь 1/3, а не какая-то псевдобесконечно повторяющаяся десятичная дробь.

При разработке систем мы должны использовать эти типы. Классический пример — работа с денежными значениями. Стоимость автомобиля в базе данных обычно хранится в виде числа, однако говорить о том, что автомобиль стоит 10 000 — это нонсенс. Валюта имеет большое значение. С помощью объектов мы можем определить тип денег, который знает и число, и валюту. Он может выполнять сложение (проверяя, совпадают ли валюты) и создавать распечатку, отформатированную нужным образом.

В таблице A.3 перечислены основные типы, используемые в этой книге.

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

Таблица А.3 Фундаментальные типы использованные в этой книге

Некоторые авторы называют такие типы литералами; однако другие авторы используют термин литерал для обозначения необъектных типов (например, типа real в C++), поэтому я использую термин фундаментальный тип.

В этой книге я не пытался дать полную спецификацию фундаментальных типов. Считайте это упражнением для читателя (или для будущего издания). Спецификация некоторых из этих типов дана в работе Кука и Дэниелса [4].