Abstract Factory

Обеспечивает семейств взаимосвязанных или зависящих друг от друга объектов без указания их конкретных классов.

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

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

Поведенческие шаблоны

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

Мы рассмотрим следующие поведенческие шаблоны:

• Iterator.
• Command.
• Observer.
• Template Method.
• Visitor.

Iterator

Предоставляет единый метод последовательного доступа к элементам коллекции, не зависящий от самой коллекции и никак с ней не связанный.

В данном случае, обязанность за создание конкретного экземпляра итератора возлагается на саму коллекцию, таким образом, коллекция является ещё и Factory. Классы, использующие Iterator – пользуются только открытым интерфейсом, получаемым из коллекции. При этом, совершенно не имеет значения какой конкретно итератор в данный момент реализует интерфейс. Примером может служить ResultSet из JDBC API, который позволяет последовательно перебирать результат запроса. При этом, классу-пользователю нет необходимости заботиться о типе и механизмах организации итератора. Это может быть открытый курсор в БД, это может быть локально буферизированная структура, итератор может подгружать данные по мере выдачи их пользователю и т.п.

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

Важно понимать, что помимо итераторов только для чтения, существуют и те, которые предоставляют возможность модификации коллекции, например удаления текущего элемента. Более того, так как итератор представляет собой состояние чтения коллекции, при изменении её состава, это состояние может оказаться неправильным. Например, указатель на текущий элемент у некоего итератора может, в результате удаления из коллекции элемента, находиться за допустимой границей. Для этого, большинством итераторов поддерживается механизм генерации Exception, в случае если в процессе работы итератор замечает, что нижележащая коллекция была изменена из другого потока.

Command

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

При необходимости абстрагироваться от способа и места выполнения операций можно использовать шаблон Command, создавая и задавая операции в виде экземпляров подклассов интерфейса Command, имеющего, в наиболее простом случае, один метод execute(). Объект-пользователь создаёт команду, которая знает «что надо делать», и передаёт ей на выполнение исполнителю (Executor). Последний, являясь в общем случае интерфейсом, может выполнять её локально, может пересылать на выполнение в другой процесс, на другой сервер и т.п. Объект-пользователь может передавать цепочку команд, чтобы те выполнились в пакетном режиме. Примером команды может послужить SQL запрос, который подготавливается клиентским процессом и отсылается на исполнение серверу.

Observer

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

Если существует необходимость посылать уведомления об изменении состояния какого либо объекта, при этом необходимо (а это, как правило, всегда желательно) сохранить слабую связанность с объектами, которым надо посылать уведомления, то целесообразно применять шаблон Observer. Объект, который может изменяться содержит внутри себя коллекцию объектов, которым нужно рассылать уведомления. По этому принципу работает событийная можель обработки в Windows, Java AWT, Java Swing,.Net Events и др. При желании получать уведомления, объект Observer, подписывается на события (добавляет себя в коллекцию целевого компонента) и тем самым получает необходимые ему уведомления. Получив уведомление, Observer может сразу же его обрабатывать, что оправдано, если обработка занимает мало времени, если же это не так – то события лучше обрабатывать в отдельных потоках (thread), в противном случае один Observer будет блокировать другие, ожидающие того же события.

Дата добавления: 2015-10-24