Паттерны проектирования. Repository & Decorator

Паттерны проектирования. Repository & Decorator

Министерство образования и науки Украины

Днепропетровский национальный университет имени Олеся Гончара

Факультет прикладной математики

Кафедра математического обеспечения ЭВМ

Реферат

По предмету: «Объектно-ориентированное программирование»

На тему: «Паттерны проектирования. Repository & Decorator»

Выполнила: Ярослава Юрьевна Чернопищенко

Днепропетровск

Паттерны проектирования (Design Patterns)

Паттернами проектирования (Design Patterns) называют решения часто встречающихся проблем в области разработки программного обеспечения. Паттерны проектирования не являются готовыми решениями, которые можно трансформировать непосредственно в код, а представляют общее описание решения проблемы, которое можно использовать в различных ситуациях.

При составлении представленного здесь каталога паттернов проектирования <#"656183.files/image001.gif">

Выступает в роли посредника между слоем домена и слоем отображения данных, предоставляя интерфейс в виде коллекции для доступа к объектам домена.

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

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

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

Принцип действия

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

Несмотря на сложные механизмы, реализованные внутри хранилища, его интерфейс очень прост. Клиент создает объект критериев, указывая характеристики объектов, которые должны быть возвращены в результате выполнения запроса. Например, чтобы найти сотрудников с указанным именем, необходимо задать объект критериев, описывая каждый критерий примерно следующим образом: criteria, equals (Person. LAST_NAME, "Fowler") и criteria, like (Person. FIRST_NAME, "M"). Затем нужно вызвать метод repository.matching (criteria), чтобы возвратить список сотрудников с фамилией Fowler, имя которых начинается на букву "М". Для большего удобства в абстрактном классе хранилища можно определить и другие методы; например, для поиска единственного соответствия было бы неплохо воспользоваться методом наподобие soleMatch (criteria) , который бы возвращал объект, а не коллекцию объектов. В число других распространенных методов входит метод поиска по идентификатору byObject id (id), который совсем несложно реализовать, используя метод soleMatch.

Клиентский код, работающий с хранилищем, воспринимает его как простую коллекцию объектов домена, расположенную в оперативной памяти. Тот факт, что объекты домена на самом деле не находятся в хранилище, полностью скрыт от клиентских программ. Разумеется, клиентский код должен быть осведомлен о том, что "видимая" коллекция объектов (например, товаров, распространяемых по каталогу) может отображаться на таблицу с сотнями тысяч записей, и применение метода all к хранилищу ProductRpository - не самая удачная идея.

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

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

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

Например, система, основанная на применении обозревателя и содержащая множество страниц запросов, нуждается в четком механизме преобразования объектов HttpRequest в результаты запроса. При наличии хранилища коду обработчика запросов будет гораздо легче преобразовать объект HttpRequest в объект критериев; передача критериев соответствующему хранилищу потребует только двух-трех дополнительных строк кода.

Назначение

Использование хранилища в большой системе с множеством типов объектов домена и массой разнообразных запросов позволяет сократить количество кода, необходимое для обработки всех этих запросов. Как уже упоминалось, хранилище использует типовое решение спецификация (в наших примерах оно представлено в виде объектов критериев), которое инкапсулирует запрос для выполнения последнего исключительно объектно-ориентированным способом. Это позволяет удалить из приложения весь код, с помощью которого выполняется настройка объекта запроса (query object) для обработки частных случаев. Клиентам никогда не придется писать запросы в SQL-выражениях; это можно осуществлять в терминах объектов. Несмотря на это, настоящие возможности хранилища проявляются в системах с несколькими источниками данных. Предположим, вам время от времени нужно осуществлять доступ к простенькому источнику данных, расположенному в оперативной памяти.

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

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

И наконец, еще одной областью применения хранилища могут стать ситуации, когда в качестве источника объектов домена используются поточные данные, предоставляемые удаленным сервером, например поток данных XML, поступающий из Internet (возможно, посредством протокола SOAP). В этом случае можно реализовать стратегию XmlFeedRepositorystrategy, которая будет считывать поток данных и преобразовывать код XML в объекты домена.

Дополнительные источники информации

Пример: поиск подчиненных заданного сотрудника (Java)

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

public class Person {List dependents() {repository = Registry.personRepository();criteria = new Criteria();.equal(Person.BENEFACTOR, this); repository.matching(criteria); }

}

Для выполнения наиболее распространенных запросов можно реализовать специализированные производные классы хранилищ. В нашем примере можно было создать класс PersonRepository, производный от Repository, и переместить создание критерия поиска в новый класс.

public class PersonRepository extends Repository {List dependentsOf(Person aPerson) {criteria = new Criteria();.equal(Person.BENEFACTOR, aPerson);matching(criteria); }

}

После этого объект Person сможет вызвать метод dependentsOf () прямо из своегохранилища PersonRepository.

public class Person {List dependents() {Registry.personRepository().dependentsOf(this);

}

}

Пример: выбор стратегий хранилища (Java)

Поскольку интерфейс хранилища надежно скрывает источник данных от слоя домена, можно изменить реализацию логики запросов внутри хранилища без изменения вызовов, поступающих от клиентов. Действительно, код домена не должен "беспокоиться" об источнике или назначении объектов домена. Когда источник данных расположен в оперативной памяти, то для обработки этого случая необходимо изменить метод matching () так, чтобы он просматривал коллекцию объектов домена на предмет соответствия заданному критерию. При этом не предполагается изменять источник данных "навсегда"; скорее, нас интересует возможность быстро переключаться между источниками данных, когда это потребуется. Отсюда следует необходимость изменить метод matching () так, чтобы он делегировал выполнение запроса тому или иному объекту стратегии. Очевидное преимущество такого подхода - возможность определить несколько стратегий, настроив каждую из них для обработки конкретной ситуации. В нашем случае целесообразно создать два объекта стратегии: объект Relationalstrategy, который будет выполнять запрос к базе данных, и объект inMemoryStrategy, который будет просматривать коллекцию объектов домена в оперативной памяти. Каждый объект стратегии реализует интерфейс Repositorystrategy, который предоставляет доступ к методу matching (), поэтому реализация класса Repository будет выглядеть, как показано ниже.

abstract class Repository {Repositorystrategy strategy;List matching(Criteria aCriteria) { strategy.matching(aCriteria); }}

public class Relationalstrategy implements Repositorystrategy {List matching(Criteria criteria) {query = new Query(myDomainObjectClass()).addCriteria(criteria);query.execute(unitOfWork()); }}

Паттерн Decorator

Декоратор - паттерн, структурирующий объекты, расширяя их функциональность. Также фигурирует под именем Wrapper.

Условия, Задача, Назначение

Динамически расширяет функциональность объекта, добавляет ему новые обязанности. Гибкая альтернатива наследованию, когда подклассы создаются только чтоб просто расширить класс новыми возможностями.

Мотивация

Иногда бывает нужно возложить дополнительные обязанности на отдельный объект, а не на класс в целом. Так, библиотека для построения графических интерфейсов пользователя должна «уметь» добавлять новое свойство, скажем, рамку или новое поведение (например, возможность прокрутки к любому элементу интерфейса).

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

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

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

Предположим, что имеется объект класса TextView, который отображает текст в окне. По умолчанию TextView не имеет полос прокрутки, поскольку они не всегда нужны. Но при необходимости их удастся добавить с помощью декоратора ScrollDecorator. Допустим, что еще мы хотим добавить жирную сплошную рамку вокруг объекта TextView. Здесь может помочь декоратор BorderDecorator.

Мы просто передаем сначала объект TextView в декоратор ScrollDecorator, и затем полученный результирующий объект передаем далее в BorderDecorator - получаем искомый результат.

Ниже на диаграмме показано, как композиция объекта TextView с объектами BorderDecorator и ScrollDecorator порождает элемент для ввода текста, окруженный рамкой и снабженный полосой прокрутки.

Классы ScrollDecorator и BorderDecorator являются подклассами Decorator - абстрактного класса, который представляет визуальные компоненты, применяемые для оформления других визуальных компонентов.- это абстрактный класс для представления визуальных объектов. В нем определен интерфейс для рисования и обработки событий. Отметим, что класс Decorator просто переадресует запросы на рисование своему компоненту, а его подклассы могут расширять эту операцию.

Подклассы Decorator могут добавлять любые операции для обеспечения необходимой функциональности. Так, операция ScrollTo объекта ScrollDecorator позволяет другим объектам выполнять прокрутку, если им известно о присутствии объекта ScrollDecorator.

Важная особенность этого паттерна состоит в том, что декораторы могут употребляться везде, где возможно появление самого объекта VisualComponent. Клиенту неважно с каким объектом работать: декорированным или недекорированным, он никоим образом не зависит от наличия или отсутствия оформлений.

паттерн поведение декоратор репозиторий

Признаки применения, использования паттерна Декоратор (Decorator)

Используйте паттерн декоратор когда:

1.      Для динамического и прозрачного для клиентов добавления новых возможностей, «фич» объектам;

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

Участники паттерна Декоратор (Decorator)

1.      Component (VisualComponent) - компонент. Класс, задает интерфейс для объектов, на которые могут быть динамически возложены дополнительные обязанности, ровно как задает его и для будущих декораторов.

.        ConcreteComponent (TextView) - конкретный компонент. Определяет объект, на который возлагаются дополнительные обязанности, вешаются дополнительные возможности.

.        Decorator - декоратор. Хранит ссылку на объект Component и наследует реализацию его интерфейса по-умалчанию;

4.      ConcreteDecorator (BorderDecorator, ScrollDecorator) - конкретный декоратор. Возлагает дополнительные обязанности на компонент.

Схема использования паттерна Декоратор (Decorator)

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

Вопросы, касающиеся реализации паттерна Декоратор (Decorator)

Применение паттерна декоратор <#"656183.files/image007.gif">

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

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

Системы МасАрр и Bedrock применяют такой подход не только для оформления видов, но и для расширения особенностей поведения объектов, связанных с обработкой событий. В обеих системах вид ведет список объектов поведения, которые могут модифицировать и перехватывать события. Каждому зарегистрированному объекту поведения вид предоставляет возможность обработать событие до того, как оно будет передано незарегистрированным объектам такого рода, за счет чего достигается переопределение поведения. Можно, например, декорировать вид специальной поддержкой работы с клавиатурой, если зарегистрировать объект поведения, который перехватывает и обрабатывает события нажатия клавиш.

Результаты

У паттерна декоратор <#"656183.files/image009.gif">

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

Например, подкласс CompressingStream сжимает данные, a ASCII7Stream конвертирует их в 7-битный код ASCII. Теперь, для того чтобы создать объект FileStream, который одновременно сжимает данные и преобразует результат в 7-битный код, достаточно просто декорировать FileStream с использованием CompressingStream и ASCII7Stream:

Stream* aStream = new CompressingStream (ASCII7Stream(FileStream ( "aFileName")>PutInt(12);>PutString("aString");

Список литературы

1.      Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. - СПб: Питер, 2001. - 368 с.: ил.

.        Фаулер, Мартин. Архитектура корпоративных программных приложений.: Пер. с англ. - М.: Издательский дом "Вильямс", 2006. - 544 с.: ил. - Парал. тит. англ.

3.      <http://design-pattern.ru/> - Справочник по паттернам проектирования