Шаблоны проектирования GoF. Структурные шаблоны. Proxy, компоновщик, Bridge | Статья в журнале «Молодой ученый»

Автор:

Рубрика: Информатика

Опубликовано в Молодой учёный №4 (138) январь 2017 г.

Дата публикации: 29.01.2017

Статья просмотрена: 125 раз

Библиографическое описание:

Григорьева Е. Ю. Шаблоны проектирования GoF. Структурные шаблоны. Proxy, компоновщик, Bridge // Молодой ученый. — 2017. — №4. — С. 156-159. — URL https://moluch.ru/archive/138/38958/ (дата обращения: 14.12.2018).



Паттерны проектирования, впервые опубликованные в книге «Design Patterns — Elements of Reusable Object-Oriented Software» Эрихом Гаммой и его товарищами, можно разделить на три группы: порождающие паттерны проектирования (Creational Patterns), структурные паттерны проектирования классов/объектов (Structural Patterns) и паттерны проектирования поведения классов/объектов (Behavioral Patterns). В этой статье я рассмотрю основные структурные шаблоны.

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

− Адаптер (Adapter);

− Декоратор (Decorator) или Оболочка (Wrapper);

− Заместитель (Proxy) или Суррогат (Surrogate);

− Компоновщик (Composite);

− Мост (Bridge), Описатель (Handle) или Тело (Body);

− Приспособленец (Flyweight);

− Фасад (Facade).

Шаблон «Заместитель» (Proxy) решает проблему, когда необходимо управлять доступом к объекту, так чтобы создавать громоздкие объекты «по требованию».

Решение заключается в следующем:

− создать суррогат громоздкого объекта. «Заместитель» хранит ссылку, которая позволяет заместителю обратиться к реальному субъекту (объект класса «Заместитель» может обращаться к объекту класса субъект, если интерфейсы «РеальногоСубъекта» и «Субъекта» одинаковы);

− Поскольку интерфейс «РеальногоСубъекта» идентичен интерфейсу «Субъекта», так, что «Заместителя» можно подставить вместо «РеальногоСубъекта», контролирует доступ к «Реальному субъекту», может отвечать за создание или удаление «РеальногоСубъекта». «Субъект» определяет общий для «РеальногоСубъекта» и «Заместителя» интерфейс так, что «Заместитель» может быть использован везде, где ожидается «РеальныйСубъект»;

− При необходимости запросы могут быть переадресованы «Заместителем» «РеальномуСубъекту».

Картинки по запросу паттерн прокси

Рис. 1. UML-диаграмма паттерна «Proxy»

По большому счету, паттерн «Декоратор» есть несколько заложенных друг в друга «Proxy», то есть «Proxy», который проксирует другой «Proxy» и т. д.

«Заместитель» может иметь и другие обязанности, а именно:

− удаленный «Заместитель» может отвечать за кодирование запроса и его аргументов и отправку закодированного запроса реальному «Субъекту»;

− виртуальный «Заместитель» может кэшировать дополнительную информацию о реальном «Субъекте», чтобы отложить его создание;

− защищающий «Заместитель» может проверять, имеет ли вызывающий объект необходимые для выполнения запроса права.

Это очень полезный шаблон, который рекомендуется, особенно начинающим программистам, постоянно держать в голове. Потому что из него выводятся другие паттерны, в том числе «Декоратор», а так же он служит постоянным напоминанием вызова классов через интерфейсы. Это второй паттерн, который автор рекомендует всем держать в голове, после «Factory method».

UML-диаграмма классов паттерна Composite

Рис. 2. UML-диаграмма шаблона «Компоновщик»

Шаблон «Компоновщик» (Composite) решает следующую проблему:

− как обрабатывать группу или композицию структур объектов одновременно?

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

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

Шаблон «Мост» (Bridge) решает следующую проблему:

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

Стандартное решение заключается в том, чтобы поместить абстракцию и реализацию в отдельные иерархии классов.

Картинки по запросу шаблон мост

Рис. 3. UML-диаграмма шаблона «Bridge»

Для примера, представим, что у нас есть бизнес-объект, у которого есть какие-то наследники. Предположим, что у нас есть класс Report и есть разные виды Report: годовой, месячный, недельный и т. д. Задача: распечатать все эти Report в форматах doc, xml, pdf. Будем делать годовой Report в трех видах и т. д.? Не хочется. Паттерн предлагает создать интерфейс, в нашем примере это будет Format, у которого будут имплементации doc, xml, pdf. Все взаимодействие происходит только через обращение интерфейса Report к Format. Никаких больше стрелочек в UML быть не должно. Поскольку абстракция и реализация, по условию паттерна, должны быть помещены в разные иерархии.

Выглядеть все должно следующим образом: годовой отчет (RefinedAbstraction) должен вызвать у своего родителя (Abstraction), абстрактного класса, у которого описаны методы, например, напечатать заголовок, напечатать таблицу, начать ячейку таблицы, закончить ячейку таблицы и т. д. Все эти методы должны быть описаны у всех типов отчетов (RefinedAbstraction), и каждый должен вызывать метод своего родителя, и не в коем случае не методы Format (Implementor). Далее каждый из методов родителя (Abstraction) должен вызывать абстрактные методы Format (Implementor), а на уровне ConcreteImplementor в зависимости от выбора конкретной имплементации метод будет обрабатываться по-своему: в html, к примеру строка запишется одним способом, в pdf другим.

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

В шаблоне «Bridge», как и во всех других шаблонах проектирования, важно понимать, что он не является законченным кодом. Его нужно дорабатывать. Более того, шаблон «Bridge» рекомендуют использовать тогда, когда в проекте две оси изменения. Если в системе три оси изменения, будет более разумно разделить её на несколько систем. Потому что такая система становится «тотально» неподдерживаемой. Разница с шаблоном заключается, по большому счету, в поставленной задаче. Поскольку в шаблоне «Bridge» проблема в том, что у нас есть некоторая абстракция (класс Report, Abstraction) и есть некоторая реализация. И нам нужно с ними что-то делать, потому что они пытаются произвести комбинаторный взрыв, перемножиться друг на друга. Чтобы этого не добиваться, мы их разделили на две половины и, действительно, свели эту задачу к чему-то похожему на абстрактную фабрику. Эти шаблоны взаимодополняющие, «Абстрактная фабрика» — создающий шаблон, «Bridge» — структурный, они работают на разных этапах.

Преимущества «Bridge» заключаются в следующем:

− отделении реализации от интерфейса, то есть, «Реализацию» «Абстракции» можно конфигурировать во время выполнения;

− разделение классов «Абстракция» и «Реализация» устраняет зависимости от реализации, устанавливаемые на этапе компиляции: чтобы изменить класс «Реализация» вовсе не обязательно перекомпилировать код.

Основной недостаток этого шаблона заключается в том, что он очень легко портится.

Литература:

  1. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб.: Питер, 2001.
  2. Ларман К. Применение UML и шаблонов проектирования. Вильямс, 2002.
  3. DeanLeffingwell, Don Widrig. Managing Software Requirements. Addison-Wesley, 2000.
  4. Rational Unified Process. Versions 2001–2003. Rational Software Corporation. http://www.rational.com/
  5. Мартин Фаулер — Архитектура корпоративных программных — М.: «Вильямс», 2007. — С. 544.
  6. Алан Шаллоуей, Джеймс Р. Тротт. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию = Design Patterns Explained: A New Perspective on Object-Oriented Design. — М.: «Вильямс», 2002. — С. 288. —ISBN 0–201–71594–5.
  7. Эрик Фримен, Элизабет Фримен. Паттерны проектирования = Head First Design Patterns. — СПб: Питер. — 656 с. — ISBN 978–5–459–00435–9.
Основные термины (генерируются автоматически): шаблон, UML, стандартное решение, ось изменения, код, класс, интерфейс, абстракция, UML-диаграмма шаблона, ячейка таблицы.


Похожие статьи

Реализация архитектурного шаблона MVC с использованием...

Интерфейс объявляет следующие абстрактные методы

Диаграмма UML, иллюстрирующая взаимосвязи между классами, приведена на рисунке 1. Рис. 1. Диаграмма классов, реализующих шаблон MVC с использованием шаблона «наблюдатель».

Шаблоны проектирования GoF. Структурные шаблоны.

Стандартное решение для паттерна «Адаптер»

Рис. 1. UML-диаграмма паттерна «Адаптер». Например, у нас есть клиентский код, которому что-то нужно.

Теоретические аспекты создания обозревателя файловой...

Для удобства восприятия материала статья включает интуитивно понятные диаграммы UML, которые

При создании модели на основе стандартных абстрактных классов необходимо

Для виджета окна просмотра представлений таблицы и дерева с помощью метода setAttribute...

Редактор диаграмм состояний гибридных систем для среды...

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

Проектирование UML-диаграмм для системы учета рабочего времени в условиях единой информационной среды Томского политехнического университета.

Использование UML при проектировании АСНИ лепестковых...

Рисунок 2 также показывает, что на основе UML диаграмм можно генерировать исходный код (прямое

Диаграмма классов UML основана на широко распространенной модели «сущность-связь», введенной

Для подключения внешних устройств разработан интерфейс IDevice.

Использование программных пакетов для решения экологических...

− Просматривать, адаптировать и использовать примеры кода, шаблоны приложений, онлайн данные и др.

При проектировании картографического веб-приложения были построены диаграммы UML.

Обучение объектно ориентированной парадигме...

...(UMLUnified Modeling Language), который по сути является открытым стандартом

Язык UML и диаграммы вариантов использования, диаграммы классов, диаграммы

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

Методологии проектирования мультиагентных систем

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

Интеграция информационных систем на основе стандартов XML...

На рис. 3 изображена диаграмма деятельности (Activity Diagram) взаимодействия с веб-сервисами в нотации UML [6, 7, 8].

Рис. 4. Фрагмент XML-шаблона. Подход к синтезу пакетов с помощью шаблонов требует

Предлагаемое решение обладает рядом преимуществ.

Обсуждение

Социальные комментарии Cackle

Похожие статьи

Реализация архитектурного шаблона MVC с использованием...

Интерфейс объявляет следующие абстрактные методы

Диаграмма UML, иллюстрирующая взаимосвязи между классами, приведена на рисунке 1. Рис. 1. Диаграмма классов, реализующих шаблон MVC с использованием шаблона «наблюдатель».

Шаблоны проектирования GoF. Структурные шаблоны.

Стандартное решение для паттерна «Адаптер»

Рис. 1. UML-диаграмма паттерна «Адаптер». Например, у нас есть клиентский код, которому что-то нужно.

Теоретические аспекты создания обозревателя файловой...

Для удобства восприятия материала статья включает интуитивно понятные диаграммы UML, которые

При создании модели на основе стандартных абстрактных классов необходимо

Для виджета окна просмотра представлений таблицы и дерева с помощью метода setAttribute...

Редактор диаграмм состояний гибридных систем для среды...

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

Проектирование UML-диаграмм для системы учета рабочего времени в условиях единой информационной среды Томского политехнического университета.

Использование UML при проектировании АСНИ лепестковых...

Рисунок 2 также показывает, что на основе UML диаграмм можно генерировать исходный код (прямое

Диаграмма классов UML основана на широко распространенной модели «сущность-связь», введенной

Для подключения внешних устройств разработан интерфейс IDevice.

Использование программных пакетов для решения экологических...

− Просматривать, адаптировать и использовать примеры кода, шаблоны приложений, онлайн данные и др.

При проектировании картографического веб-приложения были построены диаграммы UML.

Обучение объектно ориентированной парадигме...

...(UMLUnified Modeling Language), который по сути является открытым стандартом

Язык UML и диаграммы вариантов использования, диаграммы классов, диаграммы

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

Методологии проектирования мультиагентных систем

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

Интеграция информационных систем на основе стандартов XML...

На рис. 3 изображена диаграмма деятельности (Activity Diagram) взаимодействия с веб-сервисами в нотации UML [6, 7, 8].

Рис. 4. Фрагмент XML-шаблона. Подход к синтезу пакетов с помощью шаблонов требует

Предлагаемое решение обладает рядом преимуществ.

Задать вопрос