Технология разработки программного обеспечения (вторая часть) Принципы проектирования проф. каф. ОСУ Тузовский А.Ф. Лекция 6

Шаблоны разработки ПО

В разработке ПО часто встречаются проблемы, которые уже решались ранее в других проектах. В связи с тем, что контексты, в которых данная проблема решалась, могут различаются – (другой тип приложения, другая платформа или другой язык программирования), – все обычно заканчивается повторением проектирования и реализации данного решения, – тем самым возникает ситуация «повторного изобретения колеса».

Стиль мышления эксперта При решении конкретных проблем эксперты обычно не пытаются разработать новое решение, который отличается от уже имеющихся. Действия эксперта: – вспоминают аналогичную проблему, которую они уже решали, – стараются повторно используют суть ранее принятого решения для решения новой проблемы. Такой «стиль мышление» в терминах пар «проблема - решение», является общим для множества различных предметных областей, таких, как: – архитектура; – экономика; – программная инженерия.

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

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

Свойства шаблонов 1.Шаблоны описывают решения для часто повторяющихся задач проектирования, которая возникают в некоторых специфических ситуациях. 2.Шаблоны документируют накопленный, хорошо зарекомендовавший себя опыт проектирования. 3.Шаблоны определяют и описывают абстракции, которые находятся на более высоком уровне, чем уровень отдельных классов и экземпляров или компонентов. 4.Шаблоны предоставляют общий словарь терминов и общее понимание принципов проектирования.

Свойства шаблонов (2) 5.Шаблоны являются средствами документирования архитектур ПО. 6.Шаблоны поддерживают конструирование ПО с определенными свойствами. 7.Шаблоны помогают разрабатывать сложные и разнородные архитектуры ПО. 8.Шаблоны помогают справиться с сложностью ПО.

Типы паттернов В ОО анализе и проектировании разработано много различных паттернов. 1.Архитектурные паттерны. – Описывают фундаментальные способы структурирования программных систем. – Эти паттерны относятся к уровню систем и подсистем, а не классов. 2.Паттерны проектирования. – Описывают структуру программных систем в терминах классов. – Наиболее известными в этой области являются 23 паттерна, описанные в [GoF]. 3.Паттерны анализа. – Представляют общие схемы организации процесса объектно-ориентированного моделирования.

Типы шаблонов разработки ПО На этапе анализа системы: – шаблоны анализа (analysis patterns ) – комбинации классов для описания стандартных задач прикладной области; На этапе проектирования системы – шаблоны архитектуры (architecture patterns). – шаблоны проектирования (design patters); – специфичные для конкретного языка программирования идиомы.

Шаблоны архитектуры ПО Архитектурные шаблоны описывают базовые схемы структурной организации программных систем. Архитектурные шаблоны – предоставляют набор заранее определенных подсистем, – определяют их ответственности – включают правила и рекомендации по организации взаимодействия между ними.

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

Виды архитектурных шаблонов 1.Layers (Уровни), 2.Pipes and Filters (каналы и фильтры), 3.Blackboard (информационная "доска"), 4.Broker (брокер), 5.Model-View-Controller (Модель- Представление-Контроллер), 6.Presentation-Abstraction-Control (Представление-Абстракция-Контроллер), 7.Microkernel (микроядро), 8.Reflection (отражение).

Шаблоны (паттерны) проектирования

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

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

Введение в паттерны проектирования Термин «паттерн» (pattern) следует понимать как «образец». – Часто его заменяют термином «шаблон» (template). Любой паттерн описывает задачу, которая снова и снова возникает в нашей работе, а также принцип её решения, причем таким образом, что решение можно использовать миллион раз, ничего не изобретая заново. (Кристофер Александр). Такое определение паттерна существует в архитектуре (и строительстве), но оно очень подходит и для определения паттерна в программировании.

Появление паттернов проектирования Идея паттернов проектирования первоначально возникла в архитектуре. Архитектор Кристофер Александр – автор двух революционных книг, содержащих описание шаблонов в строительной архитектуре и городском планировании. Предложил общие идеи, которые используются и в областях, не имеющих отношения к архитектуре, в том числе и в программировании. 1.«A Pattern Language: Towns, Buildings, Construction» (1977 г.), 2.«The Timeless Way of Building» (1979 г.).

Развитие паттернов в программировании В 1987 году Кент Бэк (Kent Beck) и Вард Каннигем (Ward Cunningham) разработали шаблоны разработки ПО для графических оболочек на языке Smalltalk. В 1991 году Эрих Гамма совместно с Ричардом Хелмом (Richard Helm), Ральфом Джонсоном (Ralph Johnson) и Джоном Влиссидсом (John Vlissides) публикует книгу «Design Patterns Elements of Reusable Object-Oriented Software» [GoF91]. – Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. «Приемы объектно-ориентированного проектирования. Паттерны проектирования.» - СПб: Питер, с. В этой книге описаны 23 паттерна проектирования.

Мартин Фаулер (Martin Fowler) опубликовал книгу «Enterprise Patterns» описаны типичные решения при разработке корпоративных приложений, – Например, работа с базами данных, транзакциями и т.п. Джошуа Кериевски (Joshua Kerievsky) показал, как можно постоянным рефакторингом, руководствуясь базовыми принципами ООП, обеспечить эволюцию кода, перемещая его от одного паттерна к другому в зависимости от требований. После начала активного использования модульного тестирования (Unit Testing) программного кода все паттерны при этом были переосмыслены с позиций тестируемости.

Martin C. Robert, Martin Micah Agile Principles, Patterns, and Practices in C#. - Prentice Hall, 2006, 768 p. – Роберт Мартин, Мика Мартин Принципы, паттерны и методики гибкой разработки на языке C#. - Пер. с англ. – СПб.: Символ-Плюс, – 768 с. Robert C. Martin President and Chief Executive Officer Object Mentor

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

Причины возникновения паттернов проектирования В конце 80-х годов XX века в области разработки ПО (в частности, ОО проектировании) накопилось много различных похожих по своей сути решений. Эти решения требовали – систематизации, – обобщения на всевозможные ситуации, – доступного описания, способствующего пониманию их людьми, которые до этого никогда их не использовали. Такое упорядочение знаний в ОО проектировании позволило бы повторно использовать готовые и уже проверенные решения, а не снова и снова «изобретать велосипед». Решение данной проблемы взяли на себя паттерны проектирования.

Описание паттернов В общем случае каждый паттерн состоит из таких составляющих: 1. Имя является уникальным идентификатором паттерна. Имена паттернов проектирования, описанных в [GoF], являются общепринятыми. 2. Задача описывает ситуацию, в которой можно применять паттерн. 3. Решения задачи проектирования в виде паттерна определяет общие функции каждого элемента дизайна и отношения между ними. 4. Результаты представляют следствия применения паттерна.

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

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

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

Унификация терминологии Благодаря паттернам проектирования произошла: – ссылки на паттерны проектирования, как на известные решения задач, можно добавлять в проектную документацию, а также использовать в дискуссиях. Практический опыт разработки программного обеспечения говорит, что любой полученный результат всегда подлежит тщательной проверке.

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

Критерии классификации Паттерны можно классифицировать по двум критериям : – Цель -- отражает назначение паттерна. – Уровень -- говорит о том, к чему обычно применяется паттерн.

Классификация по целям паттернов проектирования 1.Порождающие паттерны (Creational Patterns). – Определяют способы создания объектов в системе. 2.Структурные паттерны (Structural Patterns). – Описывают способы построение сложных структур из классов и объектов. 3.Поведенческие паттерны (Behavioral Patterns). – Описывают способы взаимодействия между объектами.

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

Классификация паттернов проектирования Цель Уровень Порождающие паттерны Структурные паттерныПаттерны поведения КлассFactory MethodAdapter (класса)Interpreter Template Method ОбъектAbstract Factory Singleton Prototype Builder Adapter (объекта) Decorator Proxy Composite Bridge Flyweight Facade Iterator Command Observer Visitor Mediator State Strategy Memento Chain of Responsibility

Список паттернов проектирования (порождающие) 1.Factory Method (фабричный метод) – Определяет интерфейс для создания объектов, при этом выбранный класс инстанцируется подклассами. 2.Abstract Factory (абстрактная фабрика) – Предоставляет интерфейс для создания семейств, связанных между собой, или независимых объектов, конкретные классы которых неизвестны. 3.Singleton (одиночка) – Гарантирует, что некоторый класс может иметь только один экземпляр, и предоставляет глобальную точку доступа к нему. 4.Prototype (прототип) – Описывает виды создаваемых объектов с помощью прототипа и создает новые объекты путем его копирования. 5.Builder (строитель) – Отделяет конструирование сложного объекта от его представления, позволяя использовать один и тот же процесс конструирования для создания различных представлений.

Список паттернов проектирования (структурные ) 6.Adapter (адаптер) – Преобразует интерфейс класса в некоторый другой интерфейс, ожидаемый клиентами. – Обеспечивает совместную работу классов, которая была бы невозможна без данного паттерна из-за несовместимости интерфейсов. 7.Bridge (мост) – Отделяет абстракцию от реализации, благодаря чему появляется возможность независимо изменять то и другое. 8.Decorator (декоратор) – Динамически возлагает на объект новые функции. – Применяются для расширения имеющейся функциональности и являются гибкой альтернативой порождению подклассов.

Список паттернов проектирования (структурные) (2) 9.Proxy (заместитель) – Подменяет другой объект для контроля доступа к нему 10.Facade (фасад) – Предоставляет унифицированный интерфейс к множеству интерфейсов в некоторой подсистеме. – Определяет интерфейс более высокого уровня, облегчающий работу с подсистемой. 11.Composite (компоновщик) – Группирует объекты в древовидные структуры для представления иерархий типа «часть-целое». – Позволяет клиентам работать с единичными объектами так же, как с группами объектов. 12.Flyweight (приспособленец) – Использует разделение для эффективной поддержки большого числа мелких объектов.

Список паттернов проектирования (поведения) 13.Interpreter (интерпретатор) – Для заданного языка определяет представление его грамматики, а также интерпретатор предложений языка, использующий это представление. 14.Template Method (шаблонный метод) – Определяет скелет алгоритма, перекладывая ответственность за некоторые его шаги на подклассы. – Позволяет подклассам переопределять шаги алгоритма, не меняя его общей структуры. 15.Iterator (итератор) – Дает возможность последовательно обойти все элементы составного объекта, не раскрывая его внутреннего представления.

Список паттернов проектирования (поведения) (2) 16.Command (команда) – Инкапсулирует запрос в виде объекта, позволяя тем самым параметризовывать клиентов типом запроса, устанавливать очередность запросов, протоколировать их и поддерживать отмену выполнения операций. 17.Observer (наблюдатель) – Определяет между объектами зависимость типа один-ко- многим, так что при изменении состоянии одного объекта все зависящие от него получают извещение и автоматически обновляются. 18.Visitor (посетитель) – Представляет операцию, которую надо выполнить над элементами объекта. Позволяет определить новую операцию, не меняя классы элементов, к которым он применяется.

Список паттернов проектирования (поведения) (3) 19.Mediator (посредник) – Определяет объект, в котором инкапсулировано знание о том, как взаимодействуют объекты из некоторого множества. – Способствует уменьшению числа связей между объектами, позволяя им работать без явных ссылок друг на друга. – Это, в свою очередь, дает возможность независимо изменять схему взаимодействия. 20.Memento (хранитель) – Позволяет, не нарушая инкапсуляции, получить и сохранить во внешней памяти внутреннее состояние объекта, чтобы позже объект можно было восстановить точно в таком же состоянии.

Список паттернов проектирования (5) 21. State (состояние) – Позволяет объекту варьировать свое поведение при изменении внутреннего состояния. – При этом создается впечатление, что поменялся класс объекта. 22. Strategy (стратегия) – Определяет семейство алгоритмов, инкапсулируя их все и позволяя подставлять один вместо другого. – Можно менять алгоритм независимо от клиента, который им пользуется.

Список паттернов проектирования (поведения) (4) 23. Chain of Responsibility (цепочка обязанностей) – Позволяет избежать жесткой зависимости отправителя запроса от его получателя, при этом запросом начинает обрабатываться один из нескольких объектов. – Объекты-получатели связываются в цепочку, и запрос передается по цепочке, пока какой-то объект его не обработает.