Объектно-ориентированный анализ и проектирование с примерами приложений на С++

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

Для примера рассмотрим поведение классов Order и ProductRecord. Анализ первого из них дает нам следующий перечень необходимых операций:

• construct

• setCustomer

• setOrderAgent

• addItem

• removeItem

• orderID

• customer

• orderAgent

• numberOfItems

• itemAt

• quantityOf

• totalValue

Перечисленные сервисные операции можно сразу выразить на языке C++, предварительно дав два новых определения типов:

// типы идентификационных номеровtypedef unsigned int OrderID;

// тип, описывающий местную валютуtypedef float Money;

Теперь получаем следующее определение класса:

class Order {public:

Order();Order(OrderID);Order(const Order&);~Order();Orders operator=(const Orders);int operator==(const Orders) const;int operator!=(const Orders) const;void setCustomer(Customer&);void setOrderAgent(OrderAgent&);void addItem(Product&, unsigned int quantity = 1);void removeItem(unsigned int index, unsigned int quantity = 1);OrderID orderID() const;Customer& customer() const;OrderAgent& orderAgent() const;unsigned int numberOfItem() const;Product& itemAt (unsigned int) const;unsigned int quantityOf(unsigned int) const;Money totalValue() const;

protected:...};

Обратим внимание на наличие нескольких вариантов конструктора. Первый из них используется по умолчанию (Order()) для создания объекта с новым уникальным значением идентификатора OrderID. Копирующий конструктор также создает объект с уникальным идентификатором, но при этом копирует в него состояние объекта, использованного в качестве аргумента.

Последний конструктор принимает в качестве аргумента OrderID, то есть конструирует объект уже существующий в базе данных и извлекает из базы его параметры. Другими словами, в этом случае мы повторно материализуем объект, существующий в базе данных. Такая операция, безусловно, требует выполнения некоторых действий: при восстановлении объекта из базы данных соответствующий SQL-механизм должен либо сделать объект разделяемым, либо синхронизировать состояние двух объектов, созданных в разных приложениях. Детали, конечно, скрыты в реализации и недоступны клиенту, который использует объект, применяя обычный объектный интерфейс.

Реализация описанного подхода не вызывает особых затруднений. Если класс Order спроектирован так, что его состояние полностью определяется идентификатором OrderID, то реализация операций сводится к обычным операторам чтения и записи из базы данных. Копии объектов синхронизируются, поскольку соответствующая таблица в базе служит единым репозиторием состояния для всех представлений одного объекта.

Диаграмма объектов на рис. 10-6 иллюстрирует описанный SQL-механизм на примере сценария выставления счета. В сценарии реализованы следующие события:

• aClient активизирует операцию setCustomer применительно к объекту класса Order; объект класса Customer передается в качестве параметра.

• Объект класса Order вызывает селектор customerID c параметром заказчика, позволяющим получить из базы данных соответствующий первичный ключ.

• Объект, соответствующий заказу, использует SQL-оператор UPDATE, чтобы установить идентификатор заказчика в базе данных заказов.

 

Рис. 10-6. Выставление счета.