Объектно-ориентированный подход. Объектно_ориентированный_подход. Объектно ориентированный подход Мэтт Вайсфельд 5е международное издание ббк 32. 973. 2018
 Скачать 5.43 Mb.
|
|
Таблица 9.1..Кардинальность.ассоциаций.классов Необязательная/Ассоциация Кардинальность Обязательная Employee/Division 1 Обязательная Employee/JobDescription 1...n Обязательная Employee/Spouse 0...1 Необязательная Employee/Child 0...n Необязательная НОТАЦИЯ КАРДИНАЛЬНОСТИ _________________________________________________________ Нотация.0...1.означает,.что.у.работника.может.не.быть.супруга.либо.иметься.один. супруг..Нотация.0...n.означает,.что.у.работника.может.быть.любое.количество.детей. от.нуля.до.бесконечности. На рис. 9.7 показана диаграмма класса для рассматриваемой нами системы. Обратите внимание, что на этой диаграмме класса кардинальность указана вдоль ассоциативных линий. Загляните в табл. 9.1, чтобы узнать, является ли опреде- ленная ассоциация обязательной. Ассоциации, включающие множественные объекты Как нам представить ассоциацию, которая может включать множественные объекты (например, от 0 до большого количества детей) в коде? Вот код для класса Employee : import java.util.Date; public class Employee extends Person{ private String CompanyID; 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. Проверка.всех.необязательных.ассоциаций 203 Связываем.все.воедино:.пример. . Связываем все воедино: пример Поработаем над простым примером, который свяжет воедино концепции на- следования, интерфейсов, композиции, ассоциаций и агрегаций в рамках одной компактной системной диаграммы. Снова обратимся к примеру, приводившемуся в главе 8, но на этот раз с одним дополнением: мы добавим класс Owner , который будет содержать поведение walkDog Напомним, что класс Dog наследует напрямую от класса Mammal . Сплошная стрелка представляет это отношение между классами Dog и Mammal на рис. 9.9. Класс Nameable является интерфейсом, реализуемым Dog , что демонстрирует штриховая стрелка от класса Dog к интерфейсу Nameable Рис. 9.9. UML-диаграмма.для.примера.с.Dog В этой главе мы главным образом рассматривали ассоциации и агрегации. От- ношение между классами Dog и Head считается отношением агрегации, посколь- ку Head на самом деле является частью Dog . Кардинальность, указанная над линией, соединяющей эти два класса на диаграмме, определяет, что для Dog может иметься только один класс Head Отношение между классами Dog и Owner является отношением ассоциации. Owner , разумеется, не является частью Dog , и наоборот, поэтому мы можем с уверенно- стью исключить отношение агрегации. Однако классу Dog требуется услуга от Owner — поведение walkDog . Кардинальность, указанная над линией, соединяю- щей классы Dog и Owner , определяет, что для Dog может иметься один или более классов, представляющих владельцев (например, как жену, так и мужа можно Глава.9..Создание.объектов.и.объектно-ориентированное.проектирование 204 считать владельцами, совместно отвечающими за то, чтобы выводить собаку на прогулку). Определение этих отношений наследования, интерфейса, композиции, ассоци- ации и агрегации станет основной частью проектной работы, с которой вы бу- дете сталкиваться при проектировании объектно-ориентированных систем. ГДЕ HEAD? ____________________________________________________________________________ Вы,.возможно,.решите,.что.имеет.смысл.присоединить.класс. Head .к.классу. Mammal ,. а.не.к.классу. Dog ,.поскольку.в.реальной.жизни.у.всех.млекопитающих.вроде.бы.име- ется.голова..В.этой.модели.я.использовал.класс. Dog .как.центральный.элемент.при- мера,.в.силу.чего.и.прикрепил. Head .к. Dog Резюме В текущей главе мы разобрали некоторые особенности композиции, а также два ее типа — агрегацию и ассоциацию. В то время как наследование представляет новую разновидность уже существующего объекта, композиция представляет взаимодействия между разными объектами. В трех последних главах мы рассмотрели основы наследования и композиции. Используя эти концепции и применяя свои навыки в процессе разработки про- граммного обеспечения, вы сможете проектировать качественные классы и объ- ектные модели. В следующей главе мы поговорим о том, как использовать UML-диаграммы классов в качестве средств, помогающих создавать объектные модели. Ссылки Гради Буч, Роберт А. Максимчук, Майкл У. Энгл, Бобби Дж. Янг, Джим Коналлен и Келли А. Хьюстон, «Объектно-ориентированный анализ и про- ектирование с примерами приложений» (Object-Oriented Analysis and Design with Applications). — 3-е изд. — Бостон, штат Массачусетс: Addison-Wesley, 2007. Петер Коуд и Марк Мейфилд, «Проектирование на Java» (Java Design). — Аппер Сэддл Ривер, штат Нью-Джерси: Prentice-Hall, 1997. Стивен Гилберт и Билл Маккарти, «Объектно-ориентированное проектиро- вание на Java» (Object-Oriented Design in Java). — Беркли, штат Калифорния: The Waite Group Press (Pearson Education), 1998. Скотт Майерс, «Эффективное использование C++» (Effective C++). — 3-е изд. — Бостон, штат Массачусетс: Addison-Wesley Professional, 2005. Глава 10 ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ В разработке программного обеспечения интересно то, что при создании систе- мы фактически воплощается модель системы, существующей в реальном мире. К примеру, можно уверенно утверждать, что сфера информационных техноло- гий — это бизнес или она по крайней мере дополняет его. Чтобы написать программное обеспечение для бизнеса, разработчику требует- ся тщательно изучить модель работы той или иной сферы. В результате чего разработчики глубоко осведомлены о том, как проходят деловые процессы компании. Мы уже рассматривали эту концепцию на страницах этой книги, поскольку она имеет отношение к нашему обсуждению. Например, когда мы затрагивали при- менение наследования для абстрагирования поведения и атрибуты млекопита- ющих, модель была основана на тех моделях, которые существуют в действи- тельности, а не на модели, искусственно вымышленной для наших целей. Получается, что когда мы создаем класс mammal , мы можем потом применять его для построения бесконечного количества прочих классов, например dogs , cats и т. п., потому что у всех млекопитающих есть общие поведения и атрибуты. Ради познания паттернов мы изучаем собак, кошек, белок и прочих млекопита- ющих. Такие паттерны позволяют нам рассмотреть животное и определить, на самом ли деле это млекопитающее или, допустим, пресмыкающееся, у которого могут быть другие паттерны поведений и атрибутов. На протяжении всей истории люди применяли модели во многих сферах жизни, в том числе и в технической. Эти паттерны идут рука об руку со святая святых разработки программного обеспечения — повторным использованием кода. В этой главе мы рассматриваем паттерны проектирования, сравнительно новую область в разработке программного обеспечения (первая эпохальная книга о паттернах проектирования опубликована еще в 1995 году). Глава.10..Паттерны.проектирования 206 Паттерны проектирования, пожалуй, являются одним из наиболее влиятельных шагов за последние несколько лет, произошедших из движения за объектно- ориентированный подход. Сами по себе паттерны прекрасно подходят для концепции повторного использования программного кода. Из-за того, что объ- ектно-ориентированная разработка содержит в своей основе идею повторного использования кода, объектно-ориентированная разработка идет с паттернами рука об руку. Основная концепция паттернов проектирования вращается вокруг принципа лучших практик. Под лучшими практиками мы понимаем случаи, когда созда- ются подходящие эффективные решения. Такие решения документированы так, чтобы окружающие смогли получить положительные результаты из успешных действий, уже проверенных в прошлом, поскольку мы учимся методом проб и ошибок. Одна из важнейших книг по объектно-ориентированному программированию — это «Приемы объектно-ориентированного проектирования. Паттерны проекти- рования», написанная Эрихом Гаммой, Ричардом Хелмом, Ральфом Джонсоном и Джоном Влиссидесом. Эта книга стала значительной вехой в сфере разработ- ки программного обеспечения, лексика из нее распространилась в мире ком- пьютерных наук и стала невероятно популярной, поэтому авторы книги полу- чили прозвище Gang of Four (Банда четырех). В трудах по объектно-ориентированной разработке можно часто встретить упоминание Банды четырех или просто GoF. Цель этой главы — объяснить, что такое паттерны проектирования. Объяснение каждого паттерна проектирования выходит далеко за рамки этой книги и займет не один толстый том. Чтобы добиться цели этой главы, мы рассмотрим каждую из трех категорий паттернов проектирования (порождающий, структурный и поведенческий) по классификации Банды четырех и приведем по одному конкретному примеру из каждой категории. Чем хороши паттерны проектирования? Суть концепции паттернов проектирования относится не только к понятию повторного использования кода. Bзначально паттерны проектирования при- менялись при строительстве зданий и планировании городов. Как верно под- метил Кристофер Александер в работе A Pattern Language: Towns, Buildings, Construction (Язык шаблонов: города, здания, сооружения): «Каждый паттерн повторяет собой задачу, многократно возникающую в том, что нас окружает, и таким образом содержит суть решения такой задачи, тем самым позволяя повторное применение решения столько, сколько требуется, не выполняя двой- ной работы». 207 Схема.«Модель.—.Представление.—.Контроллер».в.языке.Smalltalk. . ЧЕТЫРЕ ЭЛЕМЕНТА ПАТТЕРНА ________________________________________________________ По.классификации.The.GoF.паттерн.содержит.четыре.основных.элемента: y Название.паттерна..В.нем.кратко.выражается.описание.задачи.проектирования,. ее.решений.и.последствий.ее.выполнения..Творческое.мышление.при.создании. названия.для.паттерна.непременно.расширяет.словарный.запас,.который.мы. используем.в.проектировании..Оно.помогает.проектировать.на.более.высоких. уровнях.абстракции..Благодаря.словарному.запасу,.который.мы.используем.при. создании.паттернов,.мы.можем.говорить.о.них.с.нашими.коллегами,.вести.до- кументацию.и.даже.самостоятельно.их.обдумывать..Так.легче.продумать.кон- струкции.и.отладить.их.взаимодействие.друг.с.другом..На.протяжении.периода. разработки.нашего.каталога.подбор.подходящего.названия.всегда.был.одной.из. труднейших.задач. y Задача.дает.представление,.когда.применяется.паттерн..Он.раскрывает.содер- жание.задачи..Он.может.содержать.особые.задачи.проектирования,.такие.как. представление.алгоритмов.в.виде.объектов..Он.может.содержать.описание. структур.классов.и.объектов,.которые.указывают.на.негибкость.проектирования.. Иногда.задача.включает.в.себя.список.условий,.которые.должны.быть.выполне- ны.до.применения.паттерна,.чтобы.оно.имело.смысл. y Решение.приводит.описание.элементов,.из.которых.состоит.конструкция,.их. отношения,.обязанности.и.взаимодействие..Решение.не.приводит.описаний.той. или.иной.реализации.конструкции,.поскольку.паттерн.подобен.лишь.шаблону,. который.применим.в.различных.ситуациях..Вместо.этого.паттерн.дает.абстракт- ное.описание.задачи.проектирования,.а.также.как.общее.расположение.элемен- тов.(в.нашем.случае.классов.и.объектов).эту.задачу.решает. y Последствия.—.это.результаты.и.компромиссы,.полученные.применением.пат- терна..Когда.мы.даем.описание.решениям.в.проектировании,.последствия.часто. остаются.без.огласки,.однако.стоит.заметить,.что.они.критически.важны.для. оценки.альтернативных.решений.и.для.лучшего.понимания.издержек.и.преиму- ществ.в.результате.применения.паттерна..Последствия.для.программного.обе- спечения.часто.касаются.компромиссов.в.пространстве.и.времени..Они.могут. также.решить.проблемы.языка.и.реализации..Поскольку.повторное.использова- ние.кода.часто.является.важным.фактором.в.объектно-ориентированном.про- ектировании,.последствия.применения.паттерна.оказывают.влияние.на.гибкость,. расширяемость.и.переносимость.системы..Создание.списка.последствий.по- может.ясно.понять.и.оценить.их. Схема «Модель — Представление — Контроллер» в языке Smalltalk Чтобы понимать историческую перспективу, нужно рассмотреть схему «Мо- дель — Представление — Контроллер» (MVC), впервые реализованную в Smalltalk (и применяемую в прочих языках объектно-ориентированного программирования). MVC часто применяется для наглядного объяснения Глава.10..Паттерны.проектирования 208 происхождения паттернов проектирования. Парадигма «Модель — Пред- ставление — Контроллер» применялась для создания пользовательских ин- терфейсов в Smalltalk. Smalltalk был, пожалуй, первым популярным объектно- ориентированным языком. SMALLTALK ____________________________________________________________________________ Smalltalk.—.это.результат.сочетания.нескольких.идей,.которые.зародились.в.стенах. Xerox.PARC..Эти.идеи.в.том.числе.включали.в.себя,.помимо.прочих,.применение. мыши.и.графического.оконного.интерфейса..Smalltalk.—.это.прекрасный.язык,. который.заложил.фундамент.для.дальнейшего.появления.объектно-ориентиро- ванных.языков..Иногда.разработчики.отмечают,.что.C++.на.самом.деле.не.объект- но-ориентированный,.в.то.время.как.Smalltalk.им.является..Хотя.C++.был.очень. популярен.на.заре.объектно-ориентированного.проектирования,.Smalltalk.всегда. имел.свой.узкий.круг.приверженцев..Java.же.—.это.язык,.охватывающий.и.разра- ботчиков.на.C++. Понятие паттернов проектирования распределяет роли компонентов MVC следующим образом: Модель отвечает за функционирование самого приложения, представле- ние отвечает за графическое отображение, а контроллер — за то, как ин- терфейс реагирует на ввод данных пользователем. Проблема предыдущих парадигм в том, что модель, представление и контроллер раньше были одной сущностью. Предположим, что какой-либо единый объект содержит все три компонента. В парадигме MVC у каждого из трех компонентов будут собственные интерфейсы, отделенные от интерфейсов других. Поэтому если требуется изменить интерфейс пользователя, то придется вносить изме- нения только в представление. На рис. 10.1 показана схема MVC при проекти- ровании. Рис. 10.1..Парадигма.«Модель.—.Представление.—.Контроллер» 209 Типы.паттернов.проектирования.. . Помните, многое из того, что мы изучили в области объектно-ориентированной разработки, сталкивается с проблемой интерфейсов и реализации. Насколько это возможно, мы стараемся отделить интерфейс от реализации. В той же мере мы стараемся отделять интерфейсы друг от друга. Например, мы не хотим со- четания нескольких интерфейсов, которые не имеют никакого отношения друг к другу (или к решению рассматриваемой проблемы). Парадигма MVC была одной из первых в таком разделении интерфейсов. Паттерн MVC четко определяет интерфейсы между отдельными компонентами, которые относятся к одной из основных распространенных задач в программи- ровании — созданию пользовательских интерфейсов, их связи с бизнес-логикой и данными. Если происходит разделение пользовательских интерфейсов, бизнес-логики и данных по паттерну MVC, получится гибкая и устойчивая система. Допустим, пользовательский интерфейс находится на клиентской машине, бизнес-логи- ка — на сервере приложения, а данные — на сервере для них. Разработка при- ложения таким способом позволит изменить графический интерфейс без вся- кого вмешательства в бизнес-логику и данные. Подобным образом, если нужно изменить бизнес-логику и посчитать то или иное поле по-другому, можно внести в нее изменения, не затрагивая интерфейс. И наконец, если нужно за- менить базу данных и хранить данные другим способом, можно сменить способ хранения данных на сервере без вмешательства как в интерфейс, так и в бизнес- логику. Это несомненно предполагает неизменность интерфейсов между тремя составляющими. ПРИМЕР MVC _________________________________________________________________________ В.качестве.примера.можно.привести.окно.со.списком.в.пользовательском.интер- фейсе..Представьте.графический.интерфейс,.который.включает.в.себя.список.теле- фонных.номеров..Само.окно.—.это.представление,.список.номеров.—.это.модель,. а.контроллер.представляет.собой.логику,.соединяющую.окно.и.список. |