Файл: Объектно ориентированный подход Мэтт Вайсфельд 5е международное издание ббк 32. 973. 2018.pdf

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

Глава.9..Создание.объектов.и.объектно-ориентированное.проектирование
196
В качестве примера взгляните на компьютерную систему (рис. 9.5). Как вы по- нимаете, компьютерная система — это целое. Компонентами являются монитор, клавиатура, мышь и системный блок компьютера. Каждый из них — это отдель- ный объект, однако все вместе они образуют целую компьютерную систему.
Системный блок использует клавиатуру, мышь и монитор, чтобы поручить им некоторую часть работы. Другими словами, системный блок компьютера нуж- дается в услугах мыши и при этом не способен предоставить такую услугу сам.
Поэтому он запрашивает соответствующую услугу у отдельной мыши через определенный порт и кабель, соединяющий мышь с этим системным блоком компьютера.
АГРЕГАЦИЯ В ПРОТИВОПОСТАВЛЕНИИ С АССОЦИАЦИЕЙ ____________________________
Агрегация.—.это.сложный.объект,.состоящий.из.других.объектов..Ассоциация.
.используется,.когда.одному.объекту.нужно,.чтобы.другой.объект.оказал.ему.ус- лугу.
Рис. 9.5. Ассоциации.как.отдельная.услуга
Использование ассоциаций в сочетании с агрегациями
Во всех этих примерах вы, возможно, заметили одну вещь: разделительная ли- ния между тем, что такое ассоциация, и тем, что такое агрегация, часто оказы- вается размытой. Достаточно сказать, что многие из ваших наиболее интересных проектных решений будут сводиться к выбору того, использовать ассоциации или же агрегации.
Например, образец компьютерной системы, приводившийся ранее для описания ассоциаций, также включает агрегацию. Несмотря на то что взаимодействие между системным блоком компьютера, монитором, клавиатурой и мышью яв- ляется ассоциацией, системный блок компьютера как таковой представляет собой агрегацию. Вы видите только системный блок компьютера, но на самом деле это сложная система, состоящая из других объектов, включая чипы, мате- ринскую плату, видеокарту и т. д.

197
Избегание.зависимостей. .
Допустим, объект
Employee состоит из объектов
Address и
Spouse
. Вы, возможно, посчитаете, что объект
Address является агрегацией (по сути, частью объекта
Employee
), а объект
Spouse
— ассоциацией. В целях пояснения предположим, что оба —
Employee и
Spouse
— представляют работников. Если соответствующий работник будет уволен, то
Spouse все равно останется в системе, однако произой- дет нарушение ассоциации.
Аналогичным образом, в примере со стереосистемой у ресивера имеется ассо- циация со звуковыми колонками, а также с CD-плеером. Кроме того, звуковые колонки и CD-плеер сами по себе являются агрегациями других объектов, как, например, силовые кабели.
Хотя в примере с автомобилем двигатель, свечи зажигания и двери представ- ляют композицию, стереосистема также представляет отношение ассоциации.
ОДНОГО ПРАВИЛЬНОГО ОТВЕТА НЕТ _________________________________________________
Как.и.обычно,.нет.какого-то.одного.абсолютно.правильного.ответа,.когда.дело.ка- сается.принятия.проектного.решения..Проектирование.не.является.точной.наукой..
Хотя.мы.можем.устанавливать.общие.правила,.чтобы.жить.по.ним,.они.не.являются.
жесткими.
Избегание зависимостей
При использовании композиции желательно не делать объекты сильно завися- щими друг от друга. Один из способов сделать объекты сильно зависящими друг от друга заключается в смешении доменов. Объект в одном домене не должен смешиваться с объектом в другом домене за исключением определенных ситу- аций. Вернемся к примеру со стереосистемой, чтобы разобраться в этой концеп- ции.
Если ресивер и CD-плеер будут «располагаться» в отдельных доменах, то сте- реосистему будет легче поддерживать в работоспособном состоянии. Например, если сломается такой компонент, как CD-плеер, то вы сможете отправить его в ремонт отдельно. В данном случае CD-плеер и MP3-плеер «обладают» от- дельными доменами. Это обеспечивает гибкость, например возможность купить
CD- и MP3-плеер от разных производителей. Таким образом, если вы решите заменить CD-плеер устройством от другого производителя, то сможете это сделать.
Иногда смешение доменов несет в себе определенное удобство. Хороший пример этого: существование комбинаций «телевизор/видеомагнитофон» и «телевизор/
DVD-плеер». Стоит согласиться, что сочетание обоих устройств в одном моду- ле очень удобно. Но если вдруг телевизор выйдет из строя, то плеер уже не получится использовать, поскольку в этом случае он является частью одного и того же устройства.

Глава.9..Создание.объектов.и.объектно-ориентированное.проектирование
198
Вам необходимо решить, что важнее при определенных обстоятельствах: удоб- ство или стабильность. Одного правильного ответа не существует. Все зависит от приложения и среды. В случае с комбинацией «телевизор/видеомагнитофон» мы решили, что удобство интегрированного блока значительно перевешивало риск его более низкой стабильности (рис. 9.6). Вспомните стереосистему на рис. 9.3, чтобы закрепить представление о том, что такое неинтегрированная система.
Рис. 9.6. Удобство.в.противопоставлении.со.стабильностью
СМЕШЕНИЕ ДОМЕНОВ _______________________________________________________________
Важно.понять,.обеспечит.ли.смешение.доменов.удобство..Если.преимущества.об- ладания.комбинацией.«телевизор/видеомагнитофон».перевешивают.риск.и.потен- циальное.время.простоя.отдельных.компонентов,.то.смешение.доменов.может.
оказаться.предпочтительным.выбором.при.проектировании.
Кардинальность
В книге «Объектно-ориентированное проектирование на Java» Гилберт и Мак- карти описывают кардинальность как количество объектов, участвующих в ас- социации, с указанием того, является это участие обязательным или необяза- тельным. Чтобы определить кардинальность, Гилберт и Маккарти ставят следующие вопросы.
‰
Какие именно объекты будут взаимодействовать с какими именно другими объектами?
‰
Сколько объектов будет принимать участие при каждом взаимодействии?
‰
Взаимодействие будет обязательным или необязательным?

199
Кардинальность. .
К примеру, взглянем на следующий образец. Мы создадим класс
Employee
, ко- торый будет наследовать от
Person и иметь отношения с приведенными далее классами:
‰
Division
;
‰
JobDescription
;
‰
Spouse
;
‰
Child
Что эти классы делают? Являются ли они необязательными? Сколько их тре- буется
Employee
?
‰
Division y
Этот объект содержит информацию, касающуюся отдела, в котором тру- дится работник.
y
Каждый работник должен трудиться в отделе, поэтому отношение явля- ется обязательным.
y
Работник трудится в одном и только одном отделе.
‰
JobDescription y
Этот объект содержит сведения о служебных обязанностях, в том числе, скорее всего, такую информацию, как шкала заработной платы и диапазон уровня заработной платы.
y
У каждого работника должны иметься служебные обязанности, поэтому отношение является обязательным.
y
Работник может занимать разные должности в течение срока пребывания в компании. Таким образом, у работника может иметься большое коли- чество должностных обязанностей. Сведения о них могут быть сохранены как история, если произойдет смена должности работника, либо может получиться так, работник одновременно занимает две разные должности.
Например, начальник отдела может принять на себя обязанности работ- ника, если тот уволится, а человек ему на замену еще не будет нанят.
‰
Spouse y
В этом упрощенном примере класс
Spouse содержит только дату годов- щины.
y
Работник может состоять или не состоять в браке. Таким образом,
Spouse является необязательным.
y
У работника может быть только один супруг.

Глава.9..Создание.объектов.и.объектно-ориентированное.проектирование
200
‰
Child y
В этом упрощенном примере класс
Child содержит только строку
FavoriteToy y
У работника могут иметься или не иметься дети.
y
У работника может не быть детей либо иметься несметное количество детей (ого!). Вы могли бы принять проектное решение относительно верхнего предела количества детей, с которым сможет справиться си- стема.
Чтобы можно было подытожить все это, в табл. 9.1 представлена кардинальность ассоциаций классов, которые мы только что рассмотрели.

201
Кардинальность. .
private String Title;
private Date StartDate;
private Spouse spouse;
private Child[] child;
private Division division;
private JobDescription[] jobDescriptions;
public String getCompanyID() {return CompanyID;}
public String getTitle() {return Title;}
public Date getStartDate() {return StartDate;}
public void setCompanyID(String CompanyID) {}
public void setTitle(String Title) {}
public void setStartDate(int StartDate) {}
}
Рис. 9.7. Кардинальность.на.UML-диаграмме

Глава.9..Создание.объектов.и.объектно-ориентированное.проектирование
202
Обратите внимание, что классы, для которых имеет место отношение «один ко многим», представлены в коде массивами:
private Child[] child;
private JobDescription[] jobDescriptions;
Необязательные ассоциации
Когда речь идет об ассоциациях, одним из наиболее важных аспектов является необходимость позаботиться о проектировании вашего приложения таким об- разом, чтобы оно выполняло проверку необязательных ассоциаций. Это озна- чает, что ваш код должен проверять, имеет ли место null для определенной ассоциации.
Допустим, в приводившемся ранее примере ваш код полагает, что у каждого работника есть супруг. Однако если один из работников окажется не состоящим в браке, то у кода возникнет проблема (рис. 9.8). Если ваш код в действитель- ности ожидает, что супруг будет иметься, то при его выполнении вполне может произойти сбой, что ввергнет систему в нестабильное состояние. Важно, чтобы код проводил проверку на предмет условия null
, а также обрабатывал его как допустимое условие.
Например, если супруг отсутствует, то код не должен пытаться вызывать метод
Spouse
, иначе это может привести к сбою приложения. Таким образом, код дол- жен быть способен обработать объект
Employee
, у которого нет
Spouse
Рис. 9.8. Проверка.всех.необязательных.ассоциаций