GrandM-Patterns_in_Java

Глава 3. Жизненный цикл программного обеспечения - 55

1.2.Объект TimekeepingController вызывает метод getEventType

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

1.3.Объект TimekeepingController передает тип события, полу­ ченный от пользовательского интерфейса, методу createEvent

класса TimekeepingEvent. Метод createEvent возвращает объ­ ект, в котором инкапсулировано событие.

1.4.Объект TimekeepingController передает объект события методу storeEvent объекта DаtаЬаsе для сохранения его в базе данных.

Рис. 3.7. Диаграмма взаимоцейcrвия для случая «начало смены))

Рассмотрим некоторые особенности структуры диаграммы взаимодействия,

•представленной на рис. 3.7.

Операция lookupEmployee класса Database создает объект для инкапсу­ ляции найденной информации о служащем. Шаблон Creator, описанный

в книге [Grand99], угверждает, что если объект содержит, агрегирует, запи­

сывает экземпляры класса или осуществляет инициализацию данных для экземIU1ЯРОВ класса, то такой объект является хорощим кандидатом на роль

создателя экземпляров этого класса. Поэтому объекты, которые создает операция lookupEmployee класса Database, будуг экземплярами класса

•Employee.

Событие «начало смены,) является разновидностью события системы учета

рабочего времени, поэтому объекты, представляющие это событие, являют­ ся экземплярами подкласса класса TimekeepingEvent. Будуг существовать

также и другие подклассы класса TimekeepingEvent, представляющие

другие виды событий системы учета рабочего времени. Не нужно, чтобы

Глава 3. Жизненный цикл программного обеспечения 8 57

ИЗ проекта был удален класс EmployeeBadge, поскольку механизм получения идентификационного номера сотрудника - это часть пользовательского ин­ терфейса, а не внутренней логики.

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

венность была возложена на класс Database. А это значит, что в нашем проек­ те класс TimekeepingLog не нужен, поэтому удаляем его.

Существует еще одна часть проекта, которую мы не рассматривали, - это соз­ дание отчетов по учету рабочего времени. Контролеры используют такие отче­ ты для просмотра рабочего времени их подчиненных. Специальным образом

отформатированные отчеты поступают в систему платежных ведомостей.

В отчетах события системы учета времени объединены в рабочие смены. Сме­ на - промежуток времени, в течение которого служащий находится на работе.

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

При расчете зарплаты служащего время смены делится на три категории:

1. Обычное время, оплачиваемое по стандартной почасовой ставке работника.

2. Сверхнормативное время, превышающее период обычной занятости служа­ щего. Оно оплачивается по ставке, в несколько раз превышающей ставку оплаты обычного времени.

з. Неоnлачиваемое время, за которое служащему не платят денег. Некоторые или все перерывы служащего MOryr быть неоплачиваемым временем.

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

И других вычетов.

Правила классификации при определении, ЯRЛяется ли время обычным, сверх­

нормативным или неоплачиваемым, различны для разных ситуаций, как и пра­

вила вычисления множителя, на который умножается обычная ставка при оп­

лате сверхнормативного времени. В настоящее время (,Продовольственная сеть Генри» функционирует в пределах только одного штата США. Но разрабатыва­

ются планы, которые позволят ей расшириться и развернуть свою деятельность

В других штатах. Поэтому проект должен учитывать различные правила, приме­

Няемые при классификации рабочего времени и вычислении оплаты труда слу­

жащего.

Чтобы иметь возможность выбора различных наборов правил для выполнения

Вычислений по учету рабочего времени, необходимо определить способ орга­

низации набора правил как набора объектов. Набор правил можно представить

в виде конечных автоматов, на входе которых - события системы учета рабочего

58 • Глава 3. Жизненный цикл программного обеспечения

времени, а откликом на эти входные данные являются вычисления по учету времени. На диаграмме состояний, представленной на рис. 3.9, показан пример такого конечного автомата, который моделирует правила учета рабочего време­

ни ДЛЯ штата Джорджия.

о

reguLarHours=O overtimeHours-о

uпраidНоuв-О reguLarPay-О;оvеrtimеРау-о

Рис. 3.9. Пример вычислений в системе учета рабочего времени,

выполняемых на основе состояний

Для реализации конечного автомата (рис. 3.9) можно воспользоваться шабло­

ном State, который реализует состояния класса состояний в виде классов, реа­

лизующих общий интерфейс. Диаграмма классов, изображенная на рис. 3. 1 О,

показывает использование шаблона State для реализации конечного автомата,

Глава 3. Жизненный цикл программноro обеспечения - 59

«interface» ТimekeepingStateIF

+getReguLarHours( ) : int +getOvertimeHours( ) : int +getUnpaidHours( ) : int +getReguLarPay( ) : int +getOvertimePay( ) : int +getShifts( ) : Enumeration +start( ) : 1imekeepingStateIF

+processEvent(:1imekeepingEvent) : ТimekeepingStateIF

GAТiтekeepingState

+getReguLarНours( ) : int +getOvertimeHours( ) : int +getUnpaidHours( ) : int +getReguLarPay( ) : int +getOvertimePay( ) : int I/enter( )

I/createShift( ) +getShifts( ) : Enumeration

+start( ) : TimekeepingStateIF

Рис. 3.10. Классы состояний системы учета рабочего времени

Покажем, как используются классы, изображенные на рис. 3. 1 0. Программа,

Производяшая выборку событий системы учета рабочего времени служаших из

базы данных, создает объект GATimekeepingState. Для представления каждо­

го состояния конечного автомата этот объектGATimekeepingStateиспользует экземпляр каждого своего подкласса. Метод start объекта возвращает на­

чальное состояние конечного автомата и делает это состояние текущим.

учета рабочего времени. Метод processEvent воовpauuunновое текушее со­ стояние. Когда этот метод хочет зш:тавить конечный автомат перейти в некото­ рое сост ояние, он вызывает метод enter объсJCТа состояний.

На этом закончим ИСtлсдование данной пpoбnемы. Теперь вы дOJlЖИ..Ыиметь предcтa вnение об использоваНИИ шаблонов проектироваН ИII.

-,

АЬsuш Saperdoss\ cyпepкJIIIсс) (75)

1nta1ace .od AbstnIс! CIaSS(Ивтерфе8с • aбnpamo.oIowcc)(80)

IlIIIIIU!abIe(Неюменвыll)(86)

МШer IDterface (М_витерфеАс) (91)

ProIQ' (3aмecnnu(96)ь

Шаблоны, преДСТ8ВЛСННЫС В данной главе, самые фуидамеН'I"dJ]ьные Н важные. Они активно используются другими шаблонами.

Шаблоны I:klegatlon, Interface. Abstract Superclass и lnterfacc ancl Abstracl Class

показы8З.ЮТ, как организовать отношения между клас;с8ми. Большинство шаб­ ЛОНОВ используют ХОТЯ бы один ю этих шаблонов. Они H8CТOnЬKO популярны, ЧТО чacro даЖе не упоминаются в разделе .Шаблоны, СВJlззнные с данным шаб­ ЛОНОМ проектировання» при описании большинства шаблонов.

Шаблон JmmutabIe описывает, как юбежать ошибок и задержек во время дос­

тупа мноroчнсленных объеКТОВ к одному н тому же 06ъскту. Хотя шаблон

IrnmutabIc ЯВНО не является чаcrью ПО.!1aВ1Ulюшеro большинства дрyrиx шабло­

НОВ, он испольэустся пренмушественно с другими шаблонами.

Шаблон Markcr InLerface рассматривает способ упрошения проектнровання к.. aCCOB.которые имеют постоянный атрибyr типа boolean.

Шаблон Proxy является основой ШlМ многих шаблонов, рсализуюших лопtку управления ДОСТУПОМ одноro объекта к дрyroМУ достаточно .прозрачНl..МoI" спо­

uбoМ.

Delegation • 63

ВХОДИТ В обслуживающий персонал, может быть также и пассажиром. Некоторые авиалинии иногда направляют персонал компании на работу по учету билетов. Это значит, что один и тот же субъект может играть любую из указанных ролей. При моделировании этой ситуации ДЛЯ класса Person необходимо создать семь подклассов (рис. 4.2). Количество нужных подклассов экспоненциально воз­ растает при увеличении количества ролей. Например, чтобы смоделировать все возможные комбинации для шести ролей, необходимо создать 63 подкласса.

PersonJ

Рис. 4.2. Моделирование множеcrва ролей при помощи наследования

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

С другой стороны, представление одного и того же субъекта, играюшего раз­ личные роли, можно осуществить при помощи делегирования, причем все про­ блемы решаются сами собой. Рис. 4.3 показывает, как нужно реорганизовать модель, используя делегирование.

Согласно данной структуре, объект Person делегирует ответственность по вы­

полнению определенной роли некоторому объекту, который специально пред­

назначен ДЛЯ выполнения этой роли. Таким образом, в системе вам потребуется определить столько объектов, сколько существует ролей. Различные их комби­

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

64 • Глава 4. Основные шаблоны проектирования

Рис. 4.3. Моделирование ролей при помощи делегирования

в случае с системой резервирования авиабилетов заранее определенный набор

ролевых объектов может связываться с различными объектами Person через

какое-то время. Например, при планировании рейса было определено, что на борту должно быть некоторое количество членов экипажа. При подготовке рейса определенные субъекты могут быть связаны с ролями членов экипажа.

Когда расписание меняется, субъект может быть переведен с роли члена экипа­ жа на другую.

моти в ы

© Наследование - это статическое отношение, которое не меняется со време­ нем. Если оказалось, что в разные моменты времени объект должен быть представлен разными подклассами одного и того же класса, то данный объ­ ект нельзя представить подклассом этого общего класса. Если объект созда­ ется как экземпляр какого-то класса, то он всегда будет экземпляром этого

класса. С другой стороны, в разные моменты времени объект может делеги­ ровать полномочия по своему поведению другим объектам.

© Если класс пытается сокрыть от других классов метод или переменную,

унаследованную им от суперкласса, то этот класс не должен наследоваться от такого суперкласса. Не существует способа эффективного сокрытия ме­

тодов и переменных, унаследованных от суперкласса. С другой стороны,

имеется возможность использования объектом методов и переменных дру­

гого объекта при условии, что он является единственным объектом, кото­ рый имеет доступ к другому объекту. Это очень похоже на наследование,

но здесь используются динамические отношения, которые могут меняться

со временем.

© «(Функциональный» класс (класс, имеющий отношение к функциональности программы) не должен быть подклассом вспомогательного класса. Сущест­ вуют по крайней мере две причины не делать этого:

1. При объявлении класса подклассом таких классов, как ArrayList или HashMap, есть риск того, что эти классы могут измениться впоследствии и стать несовместимыми с ужпредыдущими версиями. Хотя риск этого невелик, обычно нет таких видимых причин идти на этот риск.