158
«Молодой учёный»
. № 4 (138)
. Январь 2017 г.
Информатика
ловию паттерна, должны быть помещены в разные ие-
рархии.
Выглядеть все должно следующим образом: годовой
отчет (RefinedAbstraction) должен вызвать у своего роди-
теля (Abstraction), абстрактного класса, у которого опи-
саны методы, например, напечатать заголовок, напеча-
тать таблицу, начать ячейку таблицы, закончить ячейку
таблицы и т. д. Все эти методы должны быть описаны у
всех типов отчетов (RefinedAbstraction), и каждый должен
вызывать метод своего родителя, и не в коем случае не
методы Format (Implementor). Далее каждый из методов
родителя (Abstraction) должен вызывать абстрактные
методы Format (Implementor), а на уровне ConcreteImple-
mentor в зависимости от выбора конкретной имплемен-
тации метод будет обрабатываться по-своему: в 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.
Рис.
Do'stlaringiz bilan baham: