Проектное решение: makePayment

Системная операция makePayment выполняется при вводе кассиром внесенной за покупку суммы. Полное описание этой операции:

ОП 4: makePayment

Операция	makePayment (amount: Money)
Ссылки	Прецеденты: Оформление продажи
Предусловия	Инициирована продажа
Постусловия	Создан экземпляр p классаPayment(созданиеэкземпляра); Атрибут p.amountTendered принял значениеamount(модификация атрибута); Экземпляр pсвязан с текущим экземпляром классаSale (формирование ассоциации); Текущий экземпляр Saleсвязан с экземпляром классаStore для его добавления в журнал регистрации продаж(формирование ассоциации).

Проектное решение должно обеспечить выполнение постусловий системной операции makePayment.

Создание экземпляра Payment

Одним из постусловий описания операции является следующее:

• Создан экземпляр р объекта Payment(создание экземпляра).

При распределении обязанностей, связанных с созданием новых экземпля­ров, необходимо применять шаблон Creator.

Какой класс записывает, агрегирует, наиболее активно использует или со­держит объекты Payment?Одним из кандидатов на выполнение этой обязанно­сти может быть классRegister, поскольку он по логике записывает сведения о платежах. При таком проектном решении сокращается "разрыв между термино­логией предметной области и именами программных классов. Еще одним канди­датом может выступать классSale, поскольку он наиболее активно использует информацию объектаPayment.

При определении класса, который должен создавать новые экземпляры, можно также воспользоваться шаблоном Expert. При этом необходимо ответить на вопрос: какой из классов является экспертом в смысле инициализации дан­ных (в данном случае – внесенной суммы)? КлассRegister, выступающий в роли контроллера, получает сообщение о системной операцииmakePayment, по­этому он изначально обладает информацией о внесенной сумме. Следовательно, классRegisterснова является кандидатом на выполнение этой обязанности.

Таким образом, имеем двух кандидатов:

• Register

• Sale

Это приводит к необходимости применения главной идеи проектирования.

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

Рассмотрим каждый из этих вариантов "с точки зрения" шаблонов HighCohe­sionиLowCoupling. Если экземпляр объектаPaymentсоздается классомSale, то работа (обязанности) классаRegisterоблегчается. Кроме того, классуRegisterне нужно знать о существовании экземпляраPayment, поскольку он может записывать его опосредованно через объектSale. Это обеспечит низкий уровень связывания объ­ектаRegister. Полученная диаграмма представлена на рис. 3.8.

Рисунок 3.8 – Диаграмма взаимодействия для операции Register-makePayment

Эта диаграмма взаимодействия удовлетворяет постусловиям, приведенным в описании системной операции: создан экземпляр объекта Payment, связанный с объектомSale, и для данного платежа установлено значениеamountTendered.

Регистрация покупки

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

С точки зрения сокращения разрыва между терминологией предметной области и именами программных классов лучше всего, чтобы всей необходимой информаци­ей обладал объект Store, поскольку он связан с финансовой деятельностью пред­приятия. В качестве второго варианта можно выбрать класс, реализующий традици­онное бухгалтерское понятие, например гроссбухSalesLedger. Однако вводить до­полнительные объекты имеет смысл только при достаточном разрастании системы, когда классStoreперестанет обладать свойством зацепления (рис. 3.9).

Рисунок 3.9 – Какой класс должен отвечать за информацию о со­вершенных покупках?

Заметим, что среди постусловий в описании системной операции упомина­ется связь объектов SaleиStore. Это пример ситуации, когда постусловие не обязательно нужно реализовывать в проекте. На ранних этапах разработки речь не шла об объектеSalesLedger, однако сейчас стало ясно, что именно его мож­но использовать вместоStore. После принятия такого решения этот объект нужно будет также добавить в модель предметной области, поскольку его имя соответствует понятию реального мира. Это пример дополнительных исследова­ний и изменений модели предметной области в процессе проектирования, пред­полагаемый в рамках итеративного подхода к разработке системы.

В данном случае мы будем придерживаться исходного плана и использовать объект Store(рис. 3.10).

Рисунок 3.10 – Регистрация совершенной покупки

Вычисление причитающейся сдачи

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

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

Как обычно, если задача не сводится к выбору контроллера или к созданию новых объектов (а в данном случае это именно так), при распределении обязан­ностей необходимо воспользоваться шаблоном InformationExpertи ответить на следующий вопрос:Какой из классов отвечает за вычисление суммы сдачи (баланса торго­вой операции)?

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

Если основная обязанность по вычислению баланса возлагается на класс Payment, то для него следует обеспечить видимость классаSale, с помощью ко­торого необходимо получить общую стоимость покупки. Такой подход повышает уровень связывания классов в проекте и не соответствует основному принципу шаблонаLowCoupling.

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

Таким образом, диаграмма взаимодействия приобретает следующий вид (рис. 3.11).

Рисунок 3.11 – Диаграмма взаимодействия для операции Sale–getBalance