1.13.4. Множество систем авторизации

Допустим, мы хотим работать с множеством систем авторизации, применяя сначала самую дешевую из них, а затем другие — по мере необходимости. В этом случае нужно определить обязанности на множестве систем авторизации.

#23. Стратегия "Выбор множества"

• Как быть если нужно множество объектов, а у такого множества еще нет специального имени?

Введите множество, используя множественное число рабочего имени. Пример: системы авторизации.

Введите множество, прибавляя к рабочему имени слово "множество" или "сервер". Пример: сервер авторизации.

Необходимо множество систем авторизации, которое можно назвать:

— множество систем авторизации;

— системы авторизации;

— сервер авторизации.

А. Определение обязанностей: "что я знаю".

Данная обязанность здесь не нужна.

Б. Определение обязанностей: "кого я знаю".

Сервер авторизации знает свою систему авторизации.

Должна ли система авторизации знать свой сервер? Скорее всего нет. Объект должен знать другой объект в следующих случаях:

— "Я знаю этот объект, поэтому другие могут спросить меня о нем, и я отвечу" (Необходимость поддержки базовых запросов — причина того, что связи между объектами ограничены в обоих направлениях.)

— "Я знаю этот объект, поэтому могу послать ему сообщение, чтобы он сделал что-нибудь для меня."

Обязана ли наша система отвечать на вопрос: "Что является сервером конкретной системы авто­ризации?" Нет, не обязана, поскольку в рассматриваемой модели есть только один сервер. Поэтому не вводите ограничение для системы авторизации относительно сервера.

В. Определение обязанностей: "что я делаю".

Система авторизации знает, как:

— получить авторизацию (тип оплаты, сумма; код авторизации). Добавим сервер авторизации и его обязанности к компоненту взаимодействия систем (рис.1. 59).

Рис.1. 59. Сервер авторизации «что я знаю, кого я знаю, что я делаю»

1.13.5. Разработка динамики взаимодействия систем с помощью сценариев

Для "авторизации" объектам check (чек) и credit (кредитная карточка) необходима помощь. Здесь и вступают в действие объекты SI.

Сценарий: авторизация оплаты

Представление данного сценария показано на рис.1. 60.

Рис.1. 60. Представление сценария «авторизация оплаты»

1.14. Выбор объектов управления данными и их обязанностей

Объекты управления данными (DM) — важная часть объектной модели.

#32. Стратегия "Выбор объектов управления данными"

• Выберите объекты DM для каждого класса объектов проблемной области. Они должны быть постоянными, т.е. сохраняться в перерывах между вызовами программы.

• Используйте объекты DM для инкапсуляции механизмов поиска и хранения для всех объектов в классе проблемной области.

• Примеры: DM кассира, DM продажи, DM экземпляра строки продажи, DM экземпляра товара.

В каждом классе DM имеется ровно один объект DM, который знает соответствующие ему объек­ты PD и отвечает за управление данными в конкретном множестве объектов. Объекты DM знают и делают следующее:

Каждый объект DM знает:

— все объекты соответствующего класса проблемной области (например, объект cashier DM знает все объекты cashier);

— как вести поиск (можно попросить этот объект найти нужные объекты);

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

Важность этих объектов состоит в том, что:

— Объект DM знает, как хранить и извлекать объекты, какой бы механизм хранения данных ни применялся (плоский файл, индексированный, реляционный или объектно-ориенти­рованный).

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

— Объект DM выделяет переход из объектно-ориентированной среды в объектно неориен­тированную.

— Объект DM может кэшировать результаты работы при останове системы (если система нуждается в таком средстве).