Читайте также:
|
Применяются как для разделения, так и для объединения элементов приложения. Способы воздействия структурных шаблонов на приложение могут быть самые разные. При проектировании, часто возникает потребность в соблюдении принципов слабой связанности и высокого зацепления (low coupling and high cohesion) между классами и группами классов. Практикой было выработано много шаблонов, которые позволяют оформлять и структурировать классы, удовлетворяющие указанным принципам. Напомним, что принцип слабой связанности между группой классов диктуется потребностью разделять функциональность на относительно независимые части, с той цельлю, чтобы этими частями можно было проще манипулировать, распараллеливать разработку, взаимозаменять их при необходимости и тестировать в изолированном режиме. Принцип высокого зацепления, напротив, склоняется к тому, чтобы сходные части функциональности находились в как можно более тесной зависимости и связи друг с другом, что бы наиболее полно использовать преимущества и внутреннюю структуры друг друга. Принцив высокого зацепления на практике выражается в тенденции объединять родственную функциональность в пределах класса, группы классов или модуля. Например, в одном классе, предсталяющем «Заказ», как правило содержаться и методы для вычисления его общей стоимости, его проверки и т.п. С т.з. принципа высокого зацепления, было бы ошибочно вынести эти операции за пределы класса, так как получившийся класс «Заказ» превратился бы в простой контейнер данных, а операции были бы представлены в статических методах другого класса, что привело бы к возврату к процедурному программированию, так как нарушает одну из основных идей ООП – инкапсуляцию. С другой стороны, если имеется некторая функциоанльность, которая взимодействует с другой функциональностью, и имеется вероятность (либо это удобно с точки зрения описания бизнес процессов) того что обе функциональности могут независимо изменяться – то сильная связь между ними – осножнила бы сопровождение и развитие системы в будущем. В данном случае прибегают к принципам разделения функциональности и абстрагирования её частей с помощью обобщённых интерфейсов.
Мы рассмотрим следующие структурные шаблоны:
Adapter
Обеспечивает взаимодействие двух классов путём преобразования интерфейса одного из них таким образом, чтобы им мог пользоваться другой класс.
Предположим, что необходимо обеспечить прозрачную работу с разными модулями или классами, предоставляющими сходную функциональность, но имеющими разные интерфейсы (в примере AdapteeA и AdapteeB не имеют общих интерфейсов). Для этого, можно работать (класс Consumer) с разными версиями адаптеров, реализующих общих интерфейс, и как бы «оборачивающих» целевые классы в этот обобщённых интерфейс. Поэтому альтернативное название этого шаблона Wrapper. Обратная задача, где так же с успехом может применяться данный шаблон – необходимость подключить какую либо функциональность к уже существующей инфраструктуре. Для этого создаётся адаптер, который позволяет прозрачно, без внесения изменений ни в существующую инфраструктуру, ни в целевой модуль (или класс), подключить его. Адаптер может быть приметивным транслятором вызовов ил одного формата в другой (например вызывая методы с разными именами, или разным порядком параметров), либо совершать какие либо дополнительные действия, например, несколько вызовов к адаптеру может выражаться в одном вызове к целевому классу или модулю. Более того, адаптер может запросить дополнительные данные из стороннего источника, например из БД.
Composite
Предоставляет гибкий механизм для создания иерархических древовидных структур произвольной сложности, элементы которых могут свободно взаимодействовать с единым интерфейсом.
Предположим, что имеется некоторая иерархическая структура, произвольной вложенности, например «Проект», состоящий из подпроектов, которые в свою очередь так же могут состоять из подпроектов, а каждый попдпроект состоит из набора задач, длительность которых определена. Предположим, что для класса «Проект», согласно принципам высокого зацепления, необходимо создать метод, позволяющий получить его полную длительность (очевидно состоящию из длительность всех конечных задач, входящих во все подпроекты). Таким образом, относя этот пример к обобщённой модели, очевидно, что задача является аналогом Node, в то время проект (и подпроект как его частный случай) – классом Composite, включающим другие подпроекты и задачи. Выделив общий интерфейс и операцию (operation() – аналог вычисления длительности), можно работать с целым проектом (или с его частями) обобщённым способом через общий интерфейс, при этом, для вызывающего класса совершенно не важно, с чем конкретно осуществляется работа, с Node или с Composite, и если Composite – то неважно какого уровня вложенности. Последним достигается удовлетворение принципа слабой связанности (low coupling).
Область применения: шаблон Composite рекомендуется применять в следующих случаях:
10.4.3. Façade
Создание упрощённого интерфейса для группы подсистем или сложной подсистемы.
Часто функциональность реализуется в нескольких подсистемах или связанных классах (например domain-model/модель предметной области). Для того, чтобы избавить клиента (или подсистуму/модуль/класс) потребителя от деталей и втунтенней структуры реализации, применяют шаблон Façade, который позволяет скрыть делати структуры и предоставляет потребителям лишь фиксированный набор операций. Это позволяет впоследствии изменять внутреннюю структуру (например проводить рефакторинг (refactoring)) не изменяя и не оказывая влияния на клиентов. Кроме того, можно подменять реализации самого Façade, и, напирмер, в последствии вместо прямых вызовов, применять удалённые вызовы, типа Web Services/SOAP и т.п.
Шаблон Façade рекомендуется применять в следующих случаях:
Decorator
Предоставление механизма для добавления или удаления функциональности компонент без изменения их внешнего представления или функций.
Шаблон Decorator очень похож на шаблон Composite и Adapter, с тем отличием, что его основное назначение является изменение функциональности целевого (оборачиваемого) компонента/объекта при сохранении его интерфейса. Различные декораторы могут добавлять или изменять функциональность и поведение целевого объекта по разному. Так, например DecoratorA может добавлять операцию записи в журнал (log) перед каждым вызовом целевого компонента. Декоратор может ссылаться на другой декоратор (тем самым образуя цепочку/chain of responsibility), так как он реализует тот же самый общий интерфейс, что и целевой компонент. Декоратор может применяться для добавление функциональности журнализации, проверки прав доступа (безопасность), обеспечение транзакционности. Основным отличием от шаблона Adapter и Proxy является то, что Decorator предназначен в первую очередь для динамического добавления и удаления свойств и поведения, т.е. программа может знать о том что она добавляет и удаляет декораторы.
Шаблон Decorator рекомендуется использовать в следующих случаях:
Proxy
Является суррогатом другого объекта и может контролировать доступ к реальному целевому объекту.
Для того чтобы прокси-объект мог представлять некий реальный целевой объект, он должен реализовать точно такой же интерфейс, что и целевой объект. В ряде случаев прокси невозможно отличить от целевого объекта не прибегая в специализированным вызовам инфраструктуры. Это делается специально, что бы как можно более прозрачно встроить объект-посредник (Proxy) в цепочку вызовов. Кроме этого, часто прокси-объект должен полностью маскировать ссылку на целевой объект и не позволять клиентам получать доступ к целевому объекту напрямую, в противном случае функциональность прокси-объекта (а это может быть, например функциональность обеспечения безопасности или транзакционности) может быть обойдена.
Шаблон Proxy рекомендуется использовать в тех случаях, когда нужно разработать способ взаимодействия с объектом, работающий по более сложному сценарию, чем при использовании обычной ссылки:
Дата добавления: 2015-10-24; просмотров: 153 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Template Method | | | Аспектно-Ориентированное Программирование (Aspect Oriented Programming, AOP) |