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

Системная операция enterItemначинается с ввода кассиром кода товараitemIDи количества покупаемых единиц. Приведем полное описание этой операции.

ОП 2: enterItem

Операция	enterItem (itemID: itemID, quantity: integer )
Ссылки	Прецеденты: Оформление продажи
Предусловия	Инициирована продажа
Постусловия	Создан экземпляр sliклассаSalesLineItem(созданиеэкземпляра); Экземпляр sliсвязан с текущим экземпляром класса Sale(формирование ассоциации); Атрибуту sli.quantityприсвоено значениеquantity(модификация атрибута); Экземпляр sliсвязан с классомProductSpecification на основе соответствия идентификатора товара itemID (формирование ассоциации). Инициализированы атрибуты экземпляра s.

Диаграмма взаимодействия должна обеспечивать выполнение постусловии описания системной операции enterItem. Проектное решение принимается на основе шаблоновGRASP.

Выбор класса-контроллера

Класс-контроллер должен обрабатывать сообщение системной операции enterItem. Согласно шаблонуController, в качестве контроллера будем исполь­зовать классRegister, как и для операцииmakeNewSale.

Отображение описания товара и его цены

В соответствии с шаблоном Model-ViewSeparation, специальные объекты (такие, какRegisterиSale) не должны взаимодействовать с элементами уров­ня интерфейса пользователя (например, графическими окнами). Поэтому на данном этапе отображение описания товара и его цены не рассматривается. Пока достаточно лишь знать, что эти данные известны.

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

Среди постусловий в описании системной операции enterItemсодержатся Данные о создании экземпляра объекта SalesLineItem, его инициализации и связи с другими объектами. Анализируя модель предметной области, приходимrвыводу, что объектSaleсодержит объекты SalesLineItem, в связи с чем именно этому классу логично поручить создание экземпляров SalesLineItem.

В таком случае со временем объект Saleбудет связан с новым экземпляром коллекции продаваемых товаров. Из постусловий следует, что при создании эк­земпляра SalesLineItem необходимо указывать количество единиц покупаемого товара, поэтому данное значение необходимо передавать из объектаRegisterобъектуSale, который, в свою очередь, передаст его в качестве параметра сооб­щенияcreate(например, на языкеJavaэто можно реализовать с помощью вызова конст­руктора с параметром).

Таким образом, согласно шаблону Creator, для создания объектаSalesLineItemобъектуSaleпередается сообщениеmakeLineItem. ОбъектSaleсоздает экземпляр SalesLineItem, а затем хранит этот новый экземпляр в сво­ем постоянном контейнере.

Параметрами сообщения makeLineItemявляются количество единиц товараquantityи спецификация товараProductSpecification, соответствующая ко­ду товараitemID.

Нахождение ProductSpecification

Экземпляр SalesLineItemнеобходимо связать со спецификациейProductSpecification, соответствующей коду данного товараitemID. Это означа­ет, что необходимо уметь по коду товара находить значениеProductSpecification.

Прежде чем определять, какследует находить значениеProductSpecification, необходимо решить,ктоэто будет делать.

Переформулируем задачу следующим образом.

Кто должен отвечать за нахождение значения ProductSpecification на основе кода товара itemID?

Эта проблема не является ни задачей создания экземпляра, ни задачей вы­бора контроллера для системного события. Здесь впервые предоставляется воз­можность использования шаблона InformationExpert.

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

Проанализировав модель предметной области, приходим к выводу, что класс ProductCatalogлогически содержит полную информацию о ProductSpecification. На основе структуры объектов предметной области можно разработать аналогичную организацию программных классов: программ­ный классProductCatalogбудет содержать программные классыProductSpecification.

Следовательно, согласно шаблону Expert, классProductCatalogявляется хорошим кандидатом для реализации обязанности поиска, поскольку обладает полной информацией обо всех объектахProductSpecification.

Это можно реализовать, например, с помощью метода getSpecification.¹

Обеспечение видимости класса ProductCatalog

Кто должен отправлять сообщение getSpecification классу ProductCatalog с запросом на получение значения ProductSpecification?

Разумно предположить, что экземпляры объектов RegisterиProductCatalogдолжны быть созданы в процессе реализации прецедента Запуск системы (StartUp), и между этими объектами должна устанавливаться постоянная связь. Согласно такому предположению, отправку сообщения getSpecification для классаProductCatalogможно поручить классуRegister.

Здесь возникает еще один важный вопрос объектно-ориентированного про­ектирования: вопрос видимости. Видимость(visibility) – это способность одного объекта "видеть" другой объект или ссылаться на него. Для того чтобы один объект мог отправлять сообщения другому объекту, объ­ект-получатель должен находиться в области видимости объекта-отправителя.

Поскольку мы предположили, что объект Registerимеет постоянную связь с объектомProductCatalog(или ссылку на него), он может отправлять ему сообщения, в том числе сообщение getSpecification.

Получение значения prodactSpecification из базы данных

Очень нежелательно, чтобы в последней версии POS-системы ТТ все значения ProductSpecificationхранились в оперативной памяти. Скорее все­го, они будут храниться в реляционной или объектной базе данных, и извлекать­ся из нее по требованию. Однако пока мы не будем рассматривать вопросы из­влечения информации из базы данных, а предположим, что все значенияProductSpecificationнаходятся в оперативной памяти.

Диаграмма взаимодействия для системной операции enterItem

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

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

Сообщения сложным объектам

Заметим, что отправка сообщения сложному объекту в UMLинтерпретиру­ется как передача сообщения объекту-контейнеру, а не каждому элементу набора объектов. Это особенно очевидно для таких операций, какfindиadd.

Например, из диаграммы взаимодействия для системной операцииenterItemможно узнать следующее:

• Сообщение find, передаваемое сложному объектуProductSpecification, – это сообщение, которое отправляется один раз целому набору данных, пред­ставленному в виде сложного объекта (такому, какMapвJava).

• Независимое от языка общее сообщение findв процессе программирова­ния будет трансформировано в реальное название метода конкретной библиотеки или языка программирования. Возможно, на языкеJavaоно превратится в методMap.get. На диаграмме также можно было исполь­зовать сообщениеget. Однако мы выбрали имяfind, чтобы продемонст­рировать необходимость перехода от проектных решений к конкретным библиотекам и языкам программирования.

• Сообщение addпередается сложному объектуSalesLineItemдля добавле­ния элемента в контейнер, представленный сложным объектом (таким какListвJava).