Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
При реализации проектов по разработке программных систем и моделированию бизнес-процессов встречаются ситуации, когда решение проблем в различных проектах имеют сходные структурные черты. Попытки выявить похожие схемы или структуры в рамках объектно-ориентированного анализа и проектирования привели к появлению понятия паттерна, которое из абстрактной категории превратилось в непременный атрибут современных CASE-средств
Паттерны ООАП различаются степенью детализации и уровнем абстракции. Предлагается следующая общая классификация паттернов по категориям их применения:
Архитектурные паттерны(Architectural patterns) - множество предварительно определенных подсистем со спецификацией их ответственности, правил и базовых принципов установления отношений между ними.
Архитектурные паттерны предназначены для спецификации фундаментальных схем структуризации программных систем. Наиболее известными паттернами этой категории являются паттерны GRASP (General Responsibility Assignment Software Pattern). Эти паттерны относятся к уровню системы и подсистем, но не к уровню классов. Как правило, формулируются в обобщенной форме, используют обычную терминологию и не зависят от области приложения. Паттерны этой категории систематизировал и описал К. Ларман.
Паттерны проектирования (Design patterns) - специальные схемы для уточнения структуры подсистем или компонентов программной системы и отношений между ними.
Паттерны проектирования описывают общую структуру взаимодействия элементов программной системы, которые реализуют исходную проблему проектирования в конкретном контексте. Наиболее известными паттернами этой категории являются паттерны GoF (Gang of Four), названные в честь Э. Гаммы, Р. Хелма, Р. Джонсона и Дж. Влиссидеса, которые систематизировали их и представили общее описание. Паттерны GoF включают в себя 23 паттерна. Эти паттерны не зависят от языка реализации, но их реализация зависит от области приложения.
Паттерны анализа (Analysis patterns) - специальные схемы для представления общей организации процесса моделирования.
Паттерны анализа относятся к одной или нескольким предметным областям и описываются в терминах предметной области. Наиболее известными паттернами этой группы являются паттерны бизнес-моделирования ARIS (Architecture of Integrated Information Systems), которые характеризуют абстрактный уровень представления бизнес-процессов. В дальнейшем паттерны анализа конкретизируются в типовых моделях с целью выполнения аналитических оценок или имитационного моделирования бизнес-процессов.
Паттерны тестирования (Test patterns) - специальные схемы для представления общей организации процесса тестирования программных систем.
К этой категории паттернов относятся такие паттерны, как тестирование черного ящика, белого ящика, отдельных классов, системы. Паттерны этой категории систематизировал и описал М. Гранд. Некоторые из них реализованы в инструментальных средствах, наиболее известными из которых является IBM Test Studio. В связи с этим паттерны тестирования иногда называют стратегиями или схемами тестирования.
Паттерны реализации (Implementation patterns) - совокупность компонентов и других элементов реализации, используемых в структуре модели при написании программного кода.
Эта категория паттернов делится на следующие подкатегории: паттерны организации программного кода, паттерны оптимизации программного кода, паттерны устойчивости кода, паттерны разработки графического интерфейса пользователя и др. Паттерны этой категории описаны в работах М. Гранда, К. Бека, Дж. Тидвелла и др. Некоторые из них реализованы в популярных интегрированных средах программирования в форме шаблонов создаваемых проектов. В этом случае выбор шаблона программного приложения позволяет получить некоторую заготовку программного кода.
При разработке систем постоянно возникают вопросы, которые являются определяющими при моделировании:
как распределить обязанности между классами и объектами?
как должны взаимодействовать объекты?
какие функции выполняют конкретные классы?
Некоторые проверенные временем решения таких вопросов, возникающих во время разработки, были сформулированы в виде шаблонов (паттернов) проектирования именованных формул решения проблем, позволяющих систематизировать процесс разработки. Шаблоны проектирования позволяют не решать каждую новую задачу с нуля, а воспользоваться предыдущими удачными решениями
В хорошо структурированных системах можно найти множество образцов. Образец (Pattern) предлагает типичное решение типичной проблемы в данном контексте. Механизм - это образец проектирования, применимый к сообществу классов; каркас (Framework) - это, как правило, архитектурный образец, предлагающий расширяемый шаблон для приложений в одной конкретной области.
Образец, или паттерн (Pattern), - это типичное решение типичной проблемы в данном контексте. Механизм (Mechanism) - это образец проектирования, применимый к сообществу классов. Каркас (Framework) - это архитектурный образец, предлагающий расширяемый шаблон для приложений в одной конкретной области.
Занимаясь разработкой архитектуры новой системы или развитием существующей, вы в любом случае никогда не начинаете с нуля (см. главу 2). Напротив, прежний опыт и принятые соглашения наводят вас на мысль применить типичные способы для решения типичных проблем. Например, при построении системы, активно взаимодействующей с пользователем, вы можете прибегнуть к испытанному подходу "модель-вид-контроллер", который позволяет четко отделить объекты (модель) от их представления (вида) и от агентов, обеспечивающих синхронизацию между тем и другим (контроллеров). Аналогично при создании системы для дешифровки доказала свою полезность архитектура на основе "классной доски" (blackboard), хорошо приспособленная для решения сложных задач методом проб и ошибок.
То и другое является примером образцов, или паттернов, - типичных решений для типичных задач в данном контексте. Любая хорошо структурированная система изобилует образцами на разных уровнях абстракции. Образцы проектирования описывают структуру и поведение сообщества классов, архитектурные образцы - структуру и поведение системы в целом.
Образцы входят в UML просто потому, что являются важной составляющей словаря разработчика. Явно выделив образцы в системе, вы сделаете ее более понятной и простой для развития и сопровождения.
.
При моделировании образцов в UML помните, что они работают на многих уровнях абстракции, начиная от отдельных классов и кончая системой в целом. Самые интересные виды образцов - это механизмы и каркасы. Хорошо структурированный образец обладает следующими свойствами:
Изображая образец в UML, руководствуйтесь следующими правилами:
В 1970-е годы архитектор Кристофер Александр (англ.) составил набор шаблонов проектирования. В области архитектуры эта идея не получила такого развития, как позже в области программной разработки.
В 1987 году Кент Бэк (Kent Beck) и Вард Каннигем (Ward Cunningham) взяли идеи Александра и разработали шаблоны применительно к разработке программного обеспечения для разработки графических оболочек на языке Smalltalk.
В 1988 году Эрих Гамма (Erich Gamma) начал писать докторскую диссертацию при цюрихском университете об общей переносимости этой методики на разработку программ.
В 1989—1991 годах Джеймс Коплин (James Coplien) трудился над разработкой идиом для программирования на C++ и опубликовал в 1991 году книгу Advanced C++ Idioms.
В этом же году Эрих Гамма заканчивает свою докторскую диссертацию и переезжает в США, где в сотрудничестве с Ричардом Хелмом (Richard Helm), Ральфом Джонсоном (Ralph Johnson) и Джоном Влиссидсом (John Vlissides) публикует книгу Design Patterns — Elements of Reusable Object-Oriented Software. В этой книге описаны 23 шаблона проектирования. Также команда авторов этой книги известна общественности под названием Банда четырёх (англ. Gang of Four, часто сокращается до GoF). Именно эта книга стала причиной роста популярности шаблонов проектирования.
Главная польза каждого отдельного шаблона состоит в том, что он описывает решение целого класса абстрактных проблем. Также тот факт, что каждый шаблон имеет свое имя, облегчает дискуссию об абстрактных структурах данных (ADT) между разработчиками, так как они могут ссылаться на известные шаблоны. Таким образом, за счёт шаблонов производится унификация терминологии, названий модулей и элементов проекта.
Правильно сформулированный шаблон проектирования позволяет, отыскав удачное решение, пользоваться им снова и снова.
Иногда шаблоны консервируют громоздкую и малоэффективную систему понятий, разработанную узкой группой. Когда количество шаблонов возрастает, превышая критическую сложность, исполнители начинают игнорировать шаблоны и всю систему, с ними связанную.
Нередко шаблонами заменяется отсутствие или недостаточность документации в сложной программной среде.
Есть мнение, что слепое применение шаблонов из справочника, без осмысления причин и предпосылок выделения каждого отдельного шаблона, замедляет профессиональный рост программиста, так как подменяет творческую работу механическим подставлением шаблонов. Люди, придерживающиеся данного мнения, считают, что знакомиться со списками шаблонов надо тогда, когда «дорос» до них в профессиональном плане — и не раньше. Хороший критерий нужной степени профессионализма — выделение шаблонов самостоятельно, на основании собственного опыта. При этом, разумеется, знакомство с теорией, связанной с шаблонами, полезно на любом уровне профессионализма и направляет развитие программиста в правильную сторону. Сомнению подвергается только использование шаблонов «по справочнику».
Шаблоны могут пропагандировать плохие стили разработки приложений, и зачастую слепо применяются.
Для преодоления этих недостатков используется рефакторинг.
По словам Кристофера Александра, «любой паттерн описывает задачу, которая снова и снова возникает в нашей работе, а также принцип ее решения, причем таким образом, что это решение можно потом использовать миллион раз, ничего не изобретая заново» [AIS+77]. Хотя Александр имел в виду паттерны, возникающие при проектировании зданий и городов, но его слова верны и в отношении паттернов объектно-ориентированного проектирования. Наши решения выражаются в терминах объектов и интерфейсов, а не стен и дверей, но в обоих случаях смысл паттерна – предложить решение определенной задачи в конкретном контексте.
В общем случае паттерн состоит из четырех основных элементов:
Имя. Сославшись на него, мы можем сразу описать проблему проектирования, ее решения и их последствия. Присваивание паттернам имен позволяет проектировать на более высоком уровне абстракции. С помощью словаря паттернов можно вести обсуждение с коллегами, упоминать паттерны в документации, в тонкостях представлять дизайн системы. Нахождение хороших имен было одной из самых трудных задач при составлении каталога.
Задача. Описание того, когда следует применять паттерн. Необходимо сформулировать задачу и ее контекст. Может описываться конкретная проблема проектирования, например способ представления алгоритмов в виде объектов. Иногда отмечается, какие структуры классов или объектов свидетельствуют о негибком дизайне. Также может включаться перечень условий, при выполнении которых имеет смысл применять данный паттерн.
Решение. Описание элементов дизайна, отношений между ними, функций каждого элемента. Конкретный дизайн или реализация не имеются в виду, поскольку паттерн – это шаблон, применимый в самых разных ситуациях. Просто дается абстрактное описание задачи проектирования и того, как она может быть решена с помощью некоего весьма обобщенного сочетания элементов (в нашем случае классов и объектов).
Результаты – это следствия применения паттерна и разного рода компромиссы. Хотя при описании проектных решений о последствиях часто не упоминают, знать о них необходимо, чтобы можно было выбрать между различными вариантами и оценить преимущества и недостатки данного паттерна. Здесь речь идет и о выборе языка и реализации. Поскольку в объектно-ориентированном проектировании повторное использование зачастую является важным фактором, то к результатам следует относить и влияние на степень гибкости, расширяемости и переносимости системы. Перечисление всех последствий поможет вам понять и оценить их роль.
Здесь под паттернами проектирования понимается описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте.
Паттерн проектирования именует, абстрагирует и идентифицирует ключевые аспекты структуры общего решения, которые и позволяют применить его для создания повторно используемого дизайна. Он вычленяет участвующие классы и экземпляры, их роль и отношения, а также функции. При описании каждого паттерна внимание акцентируется на конкретной задаче объектно-ориентированного проектирования. Анализируется, когда следует применять паттерн, можно ли его использовать с учетом других проектных ограничений, каковы будут последствия применения метода. Поскольку любой проект в конечном итоге предстоит реализовывать, в состав паттерна включается пример кода на языке C++ (иногда на Smalltalk), иллюстрирующего реализацию.
Хотя, строго говоря, паттерны используются в проектировании, они основаны на практических решениях, реализованных на основных языках объектно-ориентированного программирования типа Smalltalk и C++, а не на процедурных (Pascal, C, Ada и т.п.) или объектно- ориентированных языках с динамической типизацией (CLOS, Dylan, Self). Мы выбрали Smalltalk и C++ из прагматических соображений, поскольку чаще всего работаем с ними и поскольку они завоевывают все большую популярность.
Выбор языка программирования безусловно важен. В наших паттернах подразумевается использование возможностей Smalltalk и C++, и от этого зависит, что реализовать легко, а что – трудно. Если бы мы ориентировались на процедурные языки, то включили бы паттерны наследование, инкапсуляция и полиморфизм. Некоторые из наших паттернов напрямую поддерживаются менее распространенными языками. Так, в языке CLOS есть мультиметоды, которые делают ненужным паттерн посетитель. Собственно, даже между Smalltalk и C++ есть много различий, из-за чего некоторые паттерны проще выражаются на одном языке, чем на другом (см., например, паттерн итератор).
В сфере разработки программных систем наибольшее применение получили паттерны проектирования GoF, некоторые из них реализованы в популярных средах программирования. При этом паттерны проектирования могут быть представлены в наглядной форме с помощью рассмотренных обозначений языка UML.
Паттерн проектирования в контексте языка UML представляет собой параметризованную кооперацию вместе с описанием базовых принципов ее использования.
При изображении паттерна используется обозначение параметризованной кооперации языка UML (рис. 14.1), которая обозначается пунктирным эллипсом. В правый верхний угол эллипса встроен пунктирный прямоугольник, в котором перечислены параметры кооперации, которая представляет тот или иной паттерн.
Рис. 14.1. Изображение паттерна в форме параметризованной кооперации
В последующем параметры паттерна могут быть заменены различными классами, чтобы получить реализацию паттерна в рамках конкретной кооперации. Эти параметры специфицируют используемые классы в форме ролей классов в рассматриваемой подсистеме. При связывании или реализации паттерна любая линия помечается именем параметра паттерна, которое является именем роли соответствующей ассоциации. В дополнение к диаграммам кооперации особенности реализации отдельных паттернов представляются с помощью диаграмм последовательности.
Паттерны проектирования позволяют решать различные задачи, с которыми постоянно сталкиваются проектировщики объектно-ориентированных приложений. Ниже представлен полный список паттернов проектирования GoF и краткое описание назначения каждого из них (таблица 14.1).
|
Таблица 14.1. Полный список паттернов проектирования GoF |
|||
|
№ |
Название паттерна |
Перевод |
Назначение паттерна |
|
1 |
Abstract Factory |
Абстрактная фабрика |
Предоставляет интерфейс для создания множества связанных между собой или независимых объектов, конкретные классы которых неизвестны. |
|
2 |
Adapter(синоним - Wrapper) |
Адаптер (Обертка) |
Преобразует существующий интерфейс класса в другой интерфейс, который понятен клиентам. При этом обеспечивает совместную работу классов, невозможную без данного паттерна из-за несовместимости интерфейсов. |
|
3 |
Bridge |
Мост |
Отделяет абстракцию класса от его реализации, благодаря чему появляется возможность независимо изменять то и другое. |
|
4 |
Builder |
Строитель |
Отделяет создание сложного объекта от его представления, позволяя использовать один и тот же процесс разработки для создания различных представлений. |
|
5 |
Chain of Responsibility |
Цепочка обязанностей |
Позволяет избежать жесткой зависимости отправителя запроса от его получателя, при этом объекты-получатели связываются в цепочку, а запрос передается по цепочке, пока какой-то объект его не обработает. |
|
6 |
Command |
Команда |
Инкапсулирует запрос в виде объекта, обеспечивая параметризацию клиентов типом запроса, установление очередности запросов, протоколирование запросов и отмену выполнения операций. |
|
7 |
Composite |
Компоновщик |
Группирует объекты в иерархические структуры для представления отношений типа "часть-целое", что позволяет клиентам работать с единичными объектами так же, как с группами объектов. |
|
8 |
Decorator |
Декоратор |
Применяется для расширения имеющейся функциональности и является альтернативой порождению подклассов на основе динамического назначения объектам новых операций. |
|
9 |
Facade |
Фасад |
Предоставляет единый интерфейс к множеству операций или интерфейсов в системе на основе унифицированного интерфейса для облегчения работы с системой. |
|
10 |
Factory Method |
Фабричный метод |
Определяет интерфейс для разработки объектов, при этом объекты данного класса могут быть созданы его подклассами. |
|
11 |
Flyweight |
Приспособленец |
Использует принцип разделения для эффективной поддержки большого числа мелких объектов. |
|
12 |
Interpreter |
Интерпретатор |
Для заданного языка определяет представление его грамматики на основе интерпретатора предложений языка, использующего это представление. |
|
13 |
Iterator |
Итератор |
Дает возможность последовательно перебрать все элементы составного объекта, не раскрывая его внутреннего представления. |
|
14 |
Mediator |
Посредник |
Определяет объект, в котором инкапсулировано знание о том, как взаимодействуют объекты из некоторого множества. Способствует уменьшению числа связей между объектами, позволяя им работать без явных ссылок друг на друга и независимо изменять схему взаимодействия. |
|
15 |
Memento |
Хранитель |
Дает возможность получить и сохранить во внешней памяти внутреннее состояние объекта, чтобы позже объект можно было восстановить точно в таком же состоянии, не нарушая принципа инкапсуляции. |
|
16 |
Observer |
Наблюдатель |
Специфицирует зависимость типа "один ко многим" между различными объектами, так что при изменении состояния одного объекта все зависящие от него получают извещение и автоматически обновляются. |
|
17 |
Prototype |
Прототип |
Описывает виды создаваемых объектов с помощью прототипа, что позволяет создавать новые объекты путем копирования этого прототипа. |
|
18 |
Proxy |
Заместитель |
Подменяет выбранный объект другим объектом для управления контроля доступа к исходному объекту. |
|
19 |
Singleton |
Одиночка |
Для выбранного класса обеспечивает выполнение требования единственности экземпляра и предоставления к нему полного доступа. |
|
20 |
State |
Состояние |
Позволяет выбранному объекту варьировать свое поведение при изменении внутреннего состояния. При этом создается впечатление, что изменился класс объекта. |
|
21 |
Strategy |
Стратегия |
Определяет множество алгоритмов, инкапсулируя их все и позволяя подставлять один вместо другого. При этом можно изменять алгоритм независимо от клиента, который им пользуется. |
|
22 |
Template Method |
Шаблонный метод |
Определяет структуру алгоритма, перераспределяя ответственность за некоторые его шаги на подклассы. При этом подклассы могут переопределять шаги алгоритма, не меняя его общей структуры. |
|
23 |
Visitor |
Посетитель |
Позволяет определить новую операцию, не меняя описаний классов, у объектов которых она вызывается. |
В качестве примеров рассматриваются два паттерна проектирования, которые нашли наибольшее применение при проектировании программных систем: паттерны Фасад и Наблюдатель.
Каркасы приложений
Каркас - это архитектурный образец, предлагающий расширяемый шаблон для приложений в некоторой конкретной области. Выбор такого образца вместо управляемой событиями архитектуры оказывает влияние на всю систему. Этот образец (равно как и его альтернатива) является настолько общим, что имеет смысл назвать его каркасом.
Каркас - это больше чем механизм. Фактически можно считать, что каркас - это род микроархитектуры, включающий в себя множество механизмов, совместно работающих для разрешения типичной для данной предметной области проблемы. Специфицируя каркас, вы описываете скелет архитектуры со всеми управляющими органами, которые раскрываются пользователям, желающим адаптировать этот каркас для применения в нужном контексте.
Образцы используются также для моделирования типичных архитектурных решений. При моделировании каркаса вы, собственно, моделируете инфраструктуру, которую в дальнейшем планируете повторно использовать или адаптировать к некоторому контексту.
В UML каркас моделируется в виде стереотипного пакета. Раскрыв этот пакет, вы увидите механизмы, существующие в любом из видов системной архитектуры
Каркас изображается в виде стереотипного пакета. Будучи пакетом, каркас предоставляет ряд элементов, в частности (хотя этим все разнообразие не исчерпывается) классы, интерфейсы, прецеденты, компоненты, узлы, кооперации и даже другие каркасы. Иными словами, вы помещаете в каркас все абстракции, которые, работая совместно, формируют расширяемый шаблон для приложений в конкретной области. Некоторые из этих элементов будут являться открытыми и представлять ресурсы, которые надстраивает клиент. Это стыковочные элементы каркаса, которые вы можете подсоединить к абстракциям из своего контекста. Другие открытые элементы будут являться образцами проектирования и соответствовать ресурсам, с которыми связывается клиент. Это "разъемы" каркаса, заполняемые при связывании с образцом проектирования. И наконец, некоторые элементы будут закрытыми или защищенными; они соответствуют инкапсулированным элементам каркаса, невидимым снаружи
Каркас – это набор взаимодействующих классов, составляющих повторно используемый дизайн для конкретного класса программ [Deu89, JF88]. Например, можно создать каркас для разработки графических редакторов в разных областях: рисовании, сочинении музыки или САПР [VL90, Joh92]. Другим каркасом рекомендуется пользоваться при создании компиляторов для разных языков программирования и целевых машин [JML92]. Третий упростит построение приложений для финансового моделирования [BE93]. Каркас можно подстроить под конкретное приложение путем порождения специализированных подклассов от входящих в него абстрактных классов.
Каркас диктует определенную архитектуру приложения. Он определяет общую структуру, ее разделение на классы и объекты, основные функции тех и других, методы взаимодействия объектов и классов и потоки управления. Данные параметры проектирования задаются каркасом, а прикладные проектировщики или разработчики могут сконцентрироваться на специфике приложения. В каркасе аккумулированы проектные решения, общие для данной предметной области. Акцент в каркасе делается на повторном использовании дизайна, а не кода, хотя обычно он включает и конкретные подклассы, которые можно применять непосредственно.
Повторное использование на данном уровне меняет направление связей между приложением и программным обеспечением, лежащим в его основе, на противоположное. При использовании инструментальной библиотеки (или, если хотите, обычной библиотеки подпрограмм) вы пишете тело приложения и вызываете из него код, который планируете использовать повторно. При работе с каркасом вы, наоборот, повторно используете тело и пишете код, который оно вызывает. Вам приходится кодировать операции с предопределенными именами и параметрами вызова, но зато число принимаемых вами проектных решений сокращается.
В результате приложение создается быстрее. Более того, все приложения имеют схожую структуру. Их проще сопровождать, и пользователям они представляются более знакомыми. С другой стороны, вы в какой-то мере жертвуете свободой творчества, поскольку многие проектные решения уже приняты за вас.
Если проектировать приложения нелегко, инструментальные библиотеки – еще сложнее, то проектирование каркасов – задача самая трудная. Проектировщик каркаса рассчитывает, что единая архитектура будет пригодна для всех приложений в данной предметной области. Любое независимое изменение дизайна каркаса приведет к утрате его преимуществ, поскольку основной «вклад» каркаса в приложение – это определяемая им архитектура. Поэтому каркас должен быть максимально гибким и расширяемым.
Поскольку приложения так сильно зависят от каркаса, они особенно чувствительны к изменениям его интерфейсов. По мере усложнения каркаса приложения должны эволюционировать вместе с ним. В результате существенно возрастает значение слабой связанности, в противном случае малейшее изменение каркаса приведет к целой волне модификаций.
Рассмотренные выше проблемы проектирования актуальны именно для каркасов. Каркас, в котором они решены путем применения паттернов, может лучше обеспечить высокий уровень проектирования и повторного использования кода, чем тот, где паттерны не применялись. В отработанных каркасах обычно можно обнаружить несколько разных паттернов проектирования. Паттерны помогают адаптировать архитектуру каркаса ко многим приложениям без повторного проектирования.
Дополнительное преимущество появляется потому, что вместе с каркасом документируются те паттерны, которые в нем использованы [BJ94]. Тот, кто знает паттерны, способен быстрее разобраться в тонкостях каркаса. Но даже не работающие с паттернами увидят их преимущества, поскольку паттерны помогают удобно структурировать документацию по каркасу. Повышение качества документирования важно для всех типов программного обеспечения, но для каркасов этот аспект важен вдвойне. Для освоения работы с каркасами надо потратить немало усилий, и только после этого они начнут приносить реальную пользу. Паттерны могут существенно упростить задачу, явно выделив ключевые элементы дизайна каркаса.
Поскольку между паттернами и каркасами много общего, часто возникает вопрос, в чем же различия между ними и есть ли они вообще. Так вот, существует три основных различия:
паттерны проектирования более абстрактны, чем каркасы. В код могут быть включены целые каркасы, но только экземпляры паттернов. Каркасы можно писать на разных языках программирования и не только изучать, но и непосредственно исполнять и повторно использовать. В противоположность этому паттерны проектирования, описанные в данной книге, необходимо реализовывать всякий раз, когда в них возникает необходимость. Паттерны объясняют намерения проектировщика, компромиссы и последствия выбранного дизайна;
как архитектурные элементы, паттерны проектирования мельче, чем каркасы. Типичный каркас содержит несколько паттернов. Обратное утверждение неверно;
паттерны проектирования менее специализированы, чем каркасы. Каркас всегда создается для конкретной предметной области. В принципе каркас графического редактора можно использовать для моделирования работы фабрики, но его никогда не спутаешь с каркасом, предназначенным специально для моделирования. Напротив, включенные в наш каталог паттерны разрешается использовать в приложениях почти любого вида. Хотя, безусловно, существуют и более специализированные паттерны (скажем, паттерны для распределенных систем или параллельного программирования), но даже они не диктуют выбор архитектуры в той же мере, что и каркасы.
Значение каркасов возрастает. Именно с их помощью объектно-ориентированные системы можно использовать повторно в максимальной степени. Крупные объектно-ориентированные приложения составляются из слоев взаимодействующих друг с другом каркасов. Дизайн и код приложения в значительной мере определяются теми каркасами, которые применялись при его создании.
Эта одна из категорий на которые разбивают шаблоны проектирования. В свою очередь эту категорию делят еще на два типа — паттерны порождающие объекты и паттерны порождающие классы. Первые создаются с помощью другого объекта, вторые с помощью наследования изменяют класс создаваемого объекта.
Основная идея порождающих паттернов заключается в том, что инстанцирование объектов происходит «за кадром», они скрывают в себе какие именно классы используются в приложении и детали их реализации, оставляя только интерфейсы к ним. По-идее это позволяет собрать полностью рабочее приложение из различных заготовленных заранее объектов, но по своему опыту скажу, что это практически невозможно без использования других типов шаблонов.
Их всего 5:
1. Абстрактная фабрика (Abstract Factory)
2. Одиночка (Singleton)
3. Прототип (Prototype)
4. Строитель (Builder)
5. Фабричный метод (Factory Method)
Здесь также есть два типа — паттерны уровня класса и паттерны уровня объекта. Самым ярким примером первых, на мой взгляд является «Адаптер». Общий смысл его в том, что если вдруг у нас есть класс и его интерфейсы не совместимы с другими библиотеками в нашей системе, то что бы разрешить этот конфликт, мы не изменяем код этого класса, а пишем для него адаптер. Очень часто этот паттерн применяется при написании библиотек, которые позволяют работать с различными СУБД. Паттерны уровня объекта позволяют достичь большей гибкости в приложения во время его выполнения. Наиболее популярный из них - «Декоратор».
Всего 7:
1. Адаптер (Adapter)
2. Декоратор (Decorator)
3. Заместитель (Proxy)
4. Компоновщик (Composite)
5. Мост (Bridge)
6. Приспособленец (Flyweight)
7. Фасад (Facade)
Основная идея паттернов этого типа — взаимодействие объектов и классов между собой. Но они также делятся на два уровня — паттерны поведения уровня класса и паттерны поведения уровня объекта. Здесь самое сложное это добиться наименьшей степени связанности компонентов системы друг с другом, потому что почти все объекты должны знать о существовании других и нести в себе эту информацию. Отсюда и появились такие сложные паттерны как «Посредник» и «Цепочка обязанностей».
Их 11:
1. Интерпретатор (Interpreter)
2. Итератор (Iterator)
3. Команда (Command)
4. Наблюдатель (Observer)
5. Посетитель (Visitor)
6. Посредник (Mediator)
7. Состояние (State)
8. Стратегия (Strategy)
9. Хранитель (Memento)
10. Цепочка обязанностей (Chain of Responsibility)
11. Шаблонный метод (Template Method)
Абстрактная фабрика (англ. Abstract factory) — порождающий шаблон проектирования, позволяющий изменять поведение системы, варьируя создаваемые объекты, при этом сохраняя интерфейсы. Он позволяет создавать целые группы взаимосвязанных объектов, которые, будучи созданными одной фабрикой, реализуют общее поведение. Шаблон реализуется созданием абстрактного класса Factory, который представляет собой интерфейс для создания компонентов системы (например, для оконного интерфейса он может создавать окна и кнопки). Затем пишутся наследующиеся от него классы, реализующие этот интерфейс.
|
|
Предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов, не специфицируя их конкретных классов.
И так, если вы видели группы паттернов проектирования, первый у нас по счету идет шаблон проектирования "Абстрактная фабрика". Постараюсь "просто, о сложном". Примеры приводить не стану, их и так полно - взять любую более-менее серьезную библиотеку.
При рассмотрении порождающих паттернов, обычно используется такое понятие как — объекты-продукты . Фабрика должна иметь операции, которые создают новые объекты, иначе это не фабрика, и эти самые возвращаемые фабрикой объекты, называют продуктами.
Вообще сама по себе абстрактная фабрика содержит только интерфейс для операций создающих объекты, работа с этим паттерном заключается в создании конкретных фабрик, которые будут реализовывать эти интерфейсы. Если пойти дальше, то зачастую для достижения большей гибкости, требуется так же писать абстрактные классы и для объектов-продуктов.
Если собрать все в кучу, то при разработке мы должны создать:
Первые два пункта относятся к проектированию, следующие уже к разработке. Вообще главное потрудиться над проектированием, что бы получить должный эффект от любого паттерна.
#include <iostream>
// AbstractProductA
class ICar
{
public:
virtual void printName() = 0;
};
// ConcreteProductA1
class Ford : public ICar
{
public:
virtual void printName()
{
std::cout << "Ford" << std::endl;
}
};
// ConcreteProductA2
class Toyota : public ICar
{
public:
virtual void printName()
{
std::cout << "Toyota" << std::endl;
}
};
// AbstractProductB
class IEngine
{
public:
virtual void printPower() = 0;
};
// ConcreteProductB1
class FordEngine : public IEngine
{
public:
virtual void printPower()
{
std::cout << "Ford Engine 4.4" << std::endl;
}
};
// ConcreteProductB2
class ToyotaEngine : public IEngine
{
public:
virtual void printPower()
{
std::cout << "Toyota Engine 3.2" << std::endl;
}
};
// AbstractFactory
class ICarFactory
{
public:
virtual ICar* createCar() = 0;
virtual IEngine* createEngine() = 0;
};
// ConcreteFactory1
class FordFactory : public ICarFactory
{
public:
// from ICarFactory
virtual ICar* createCar()
{
return new Ford();
}
virtual IEngine* createEngine()
{
return new FordEngine();
}
};
// ConcreteFactory2
class ToyotaFactory : public ICarFactory
{
public:
// from ICarFactory
virtual ICar* createCar()
{
return new Toyota();
}
virtual IEngine* createEngine()
{
return new ToyotaEngine();
}
};
void use(ICarFactory* f)
{
ICar* myCar = f->createCar();
IEngine* myEngine = f->createEngine();
myCar->printName();
myEngine->printPower();
delete myCar;
delete myEngine;
}
int main()
{
ToyotaFactory toyotaFactory;
FordFactory fordFactory;
use (&toyotaFactory);
use (&fordFactory);
return 0;
}
Что мы получим в итоге?
На тот момент, когда будет много кода и реализованного функционала в целом по приложению — можно будет переключаться между фабриками и получать различные семейства объектов, это достигается тем, что программа (или скрипт) пользуется абстрактными методами фабрики, а в них инкапсулирована работа с классами продуктов.
Продолжая начатое, рассмотрим теперь паттерн singleton. Думаю основная его идея ясна из названия, но все же постараюсь коротко изложить смысл использования этого шаблона.
Основное предназначение этого паттерна заключается в том, что бы получить один и только один экземпляр класса в системе и предоставить интерфейс к нему т.е. сделать легко-доступным во всем приложении и не позволять создавать объекты этого класса. Класс можно модифицировать, только расширяя его, и потом порождая с его помощью объекты этих "модифицированных классов".
Класс "Одиночка" должен иметь как миниму одну операцию - Instance она предоставляет доступ к единственному экземпляру. Как правило это статичная функция.
Одним из преимуществ является то что благодаря использованию, этого паттерна и единственному экземпляру, прастранство имен освобождается от множества глобальных переменных.
Шаблоны параллельного программирования используется для более эффективного написания многопоточных программ, и предоставляет готовые решения проблем синхронизации.
Также на сегодняшний день существует ряд других шаблонов:
нти-паттерны (anti-patterns), также известные как ловушки (pitfalls) — это классы наиболее часто внедряемых плохих решений проблем. Они изучаются, как категория, в случае когда их хотят избежать в будущем, и некоторые отдельные случаи их могут быть распознаны при изучении неработающих систем.
Термин происходит из информатики, из книги «Банды четырёх» Шаблоны проектирования, которая заложила примеры практики хорошего программирования. Авторы назвали эти хорошие методы «шаблонами проектирования», и противоположными им являются «анти-паттерны». Частью хорошей практики программирования является избегание анти-паттернов.
Концепция также прекрасно подходит к машиностроению. Несмотря на то, что термин нечасто используется вне программной инженерии, концепция является универсальной.
Содержание[убрать]
|
См. Категория:Анти-паттерны для более подробного списка.
В объектно-ориентированном программировании божественный объект (англ. God object) — это объект, который хранит в себе «слишком много» или делает «слишком много». Является примером анти-паттерна.
Основная идея структурного программирования состоит в том, что большая задача делится на маленькие подзадачи (принцип «разделяй и властвуй»). В объектно-ориентированном программировании этот принцип выражается в создании множества объектов, каждый из которых решает только свою собственную задачу.
Подход «божественного объекта» противоположен этому принципу: основная часть функциональности программы кодируется в одном объекте. Так как этот объект хранит большое количество данных и имеет много методов, его роль в программе становится «божественной» (всеобъемлющей).
Вместо того, чтобы общаться друг с другом непосредственно, другие объекты полагаются на божественный объект. Так как на божественный объект ссылается так много кода, его обслуживание (внесение изменений) становится сложным: велик риск сломать существующую функциональность.
Божественный объект — это объектно-ориентированный аналог отказа от использования подпрограмм в процедурном программировании или использования слишком большого количества глобальных переменных для хранения информации о состоянии программы.
Хотя божественный объект считается плохой практикой программирования, поскольку вредит поддерживаемости кода, они могут быть полезны для работы при ограниченных ресурсах (в микроконтроллерах или мобильных телефонах), где производительность важнее, чем поддерживаемость кода.
.
Статус некоторых из них может быть спорным.
PAGE 25