1 of 59

SWEBOK. Область знаний «Проектирование ПО».�III. Типовые решения

МСПИСТ

13.09.2016 г.

Лекция 10

2 of 59

Типовые решения в проектировании ПО

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

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

http://books.google.ru/books?id=0kUFZDuqvmEC&pg=PA360&lpg=PA360&dq=%22What+is+a+Pattern+System?%22&source=bl&ots=MJuACU6sIy&sig=Q84Llgr_J_SwKxMRRm8kVq55ZkU&hl=ru&sa=X&ei=D4eWT-uYIob_-gbGmoX4DQ&ved=0CDYQ6AEwAg#v=onepage&q=%22What%20is%20a%20Pattern%20System%3F%22&f=false

4.5 DESIGN PATTERNS

(шаблон, паттерн, типовое решение)

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

In software design, one frequently encounters a problem that one has solved before on a different project.

Often the context of the problem is different; it might be a different application, a different platform, or a different programming language.

Because of the different context, one usually ends up redesigning and reimplementing the solution, thereby falling into the “reinventing the wheel” trap.

The field of software patterns, including architectural and design patterns, is helping developers avoid unnecessary redesign and reimplementation.

The concept of a pattern was first developed by Christopher Alexander in the architecture of buildings and described in his book «The Timeless Way of Building» (Alexander 1979).

In software, the field of design patterns was popularized by Gamma, Helms, Johnson, and Vlissides in their book Design Patterns (1995), in which they described 23 design patterns.

Later, Buschmann et al. (1996) described patterns that span different levels of abstraction, from high-level architectural patterns through design patterns to low-level idioms.

=====================

Из Wikipedia -

«The Timeless Way of Building» is a 1979 book by Christopher Alexander that proposes a new theory of architecture (and design in general) that relies on the understanding and configuration of design patterns.

It is essentially the introduction to A Pattern Language and The Oregon Experiment, providing the philosophical background to the Center for Environmental Structure series.

It has had a huge influence on creative thinking, especially in the areas of architecture and software design.

In the book, Alexander introduces the concept of the "quality without a name", and argues that we should seek to include this nameless quality in our buildings.

Alexander attempts to define the idea by surrounding it with existing concepts that reflect a part of the quality with no name but are not sufficient to define it individually.

The book's format is somewhat unusual. It is written as a long series of italicized headlines followed by short sections providing more detail;

as Alexander suggests in the foreword, the 552-page book can be read in an hour by only reading the headlines, which frame the book's argument.

There are also numerous full-page photo illustrations throughout the book, some of which are referenced by the text and some of which are simply an additional visual argument to complement the words.

The style used in The Timeless Way of Building is also unusual for an architectural text, at times resembling prose poetry or religious scripture.

Indeed, some consider it not primarily an architectural work at all but "a book on philosophy with architectural examples."

Other books in the same series are:

A Pattern Language (volume 2)

The Oregon Experiment (volume 3)

=====================

3 of 59

Кристофер Александер:

«Каждое типовое решение описывает некую повторяющуюся проблему и ключ к ее разгадке, причем таким образом, что вы можете пользоваться этим ключом многократно, ни разу не придя к одному и тому же результату»
Alexander et al. A Pattern Language — Oxford, 1977.

(Фаулер): К. Александер— архитектор, и говорит он о сооружениях, но данное им определение, по моему мнению, прекрасно подходит и для типовых решений в программировании. Основа типового решения — подход, достаточно обший и

эффективный для того, чтобы обеспечить преодоление периодически возникающих про-

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

рекомендации: искусство создания типовых решений состоит в вычленении и кристал-

лизации таких относительно независимых рекомендаций, которые допускают возмож-

ность более или менее обособленного применения.

4 of 59

Стиль мышления эксперта

При решении конкретных проблем эксперты обычно не пытаются разработать новое решение, который отличается от уже имеющихся.
Действия эксперта:

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

Такой «стиль мышление» в терминах пар «проблема - решение», является общим для множества различных предметных областей, таких, как:

архитектура;
экономика;
программная инженерия.

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

When experts work on a particular problem, it is unusual for them to tackle it by inventing a new solution that is completely distinct from existing ones.

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

They often recall a similar problem they have already solved, and reuse the essence of its solution to solve the new problem.

Такой «стиль поведения», мышление в терминах пар «проблема - решение», является общим для множества различных предметных областей, таких, как:

архитектура;
экономика;
программная инженерия.

This kind of ‘expert behavior’, the thinking in problem-solution pairs, is common to many different domains, such as architecture [Ale79], economics [Etz64] and software engineering [BJ94].

It is a natural way of coping with any kind of problem or social interaction [NS72].

5 of 59

Кристофер Александер:

Каждое типовое решение описывает задачу, которая снова и снова возникает в нашей работе, а также принцип её решения, причем таким образом, что решение можно использовать миллион раз, ничего не изобретая заново. (Кристофер Александр).

Alexander et al. A Pattern Language — Oxford, 1977.

1. Введение в паттерны проектирования

Такое определение паттерна существует в архитектуре (и строительстве), но оно очень подходит и для определения паттерна в программировании.

Термин «паттерн» (pattern) следует понимать как «образец».

Часто его заменяют термином «шаблон» (template).

По словам Кристофера Александра¹, «... любой паттерн описывает задачу, которая снова и снова возникает в нашей работе, а также принцип её решения, причем таким образом, что решение можно использовать миллион раз, ничего не изобретая заново...» [GoF95].

(¹ Кристофер Александр — архитектор, составивший в 1970-х годах XX ст. каталог паттернов проектирования в области строительной архитектуры.

Позже его идея получила широкое развитие в области разработки программного обеспечения.)

Такое определение паттерна существует в архитектуре (т.е. строительстве), но оно очень подходит и для определения паттерна в программировании.

Все примеры практического использования паттернов представлены на языке С#, их исходные коды прилагаются к уроку.

6 of 59

Причины возникновения типовых решений в проектировании ПО

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

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

Такое упорядочение знаний в ОО проектировании позволило бы повторно использовать готовые и уже проверенные решения
Решение данной проблемы взяли на себя шаблоны (паттерны) проектирования.

1.2. Причины возникновения паттернов проектирования

В конце 80-х годов XX века в сфере разработки программного обеспечения, в частности, объектно-ориентированном проектировании, накопилось много различных сходных по своей сути решений.

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

Такое упорядочение знаний в объектно-ориентированном проектировании позволило бы повторно использовать готовые и уже проверенные решения, а не снова и снова «изобретать велосипед».

Решение проблемы систематизации накопленного опыта в объектно-ориентированном проектировании, а также представление его широкому кругу разработчиков и взяли на себя паттерны проектирования.

7 of 59

Зачем нужны шаблоны

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

Шаблоны позволяют основываться на коллективном опыте квалифицированных инженеров по проектированию ПО (ТРПО).

Patterns help you build on the collective experience of skilled software engineers.

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

They capture existing, well-proven experience in software development and help to promote good design practise.

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

Every pattern deals with a specific, recurring problem in the design or implementation of a software system.

Шаблоны могут использоваться для создания архитектур ПО с конкретными свойствами.

Patterns can be used to construct software architectures with specific properties.

In this chapter we give an in-depth explanation of what patterns for software architecture are, and how they help you build software.

8 of 59

Определение шаблона (Pattern)

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

определения используемых (составляющих) компонент;
их ответственностей;
способов их взаимодействия.

9 of 59

Свойства шаблонов

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

We can derive several properties of patterns for software architecture from this introductory example

(if not stated otherwise, we use the terms pattern and pattern for software architecture as synonyms):

A pattern addresses a recurring design problem that arises in specific design situations, and presents a solution to it.

2. Patterns document existing, well-proven design experience.

3. Patterns identify and specify abstractions that are above the level of single classes and instances, or of components.

4. Patterns provide a common vocabulary and understanding for design principles.

5. Patterns are a means of documenting software architectures.

6. Patterns support the construction of software with defined properties.

7. Patterns help you build complex and heterogeneous software architectures.

8. Patterns help you to manage software complexity.

10 of 59

Иерархия типовых решений

Архитектурные стили (шаблоны архитектуры) - п. 3.2 в Swebook

Описывают фундаментальные способы структурирования программных систем.
Относятся к уровню систем и подсистем, а не классов

Шаблоны проектирования - п. 3.3 в Swebook

Описывают структуру программных систем в терминах классов и объектов
Идиомы, специфичные для конкретного языка программирования.

11 of 59

Шаблоны архитектуры ПО

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

12 of 59

Шаблоны архитектуры ПО (2)

Влияют на:

коммуникацию и взаимодействие между разными частями системы;
их последующее расширение.

Каждый архитектурный шаблон помогает разработчику достигнуть некоторого глобального свойства разрабатываемой системы,

Например, адаптируемости пользовательского интерфейса.

13 of 59

Примеры архитектурных шаблонов

Layers (Уровни),
Pipes and Filters (каналы и фильтры),
Blackboard (информационная "доска"),
Broker (брокер),
Model-View-Controller (Модель-Представление-Контроллер),
Presentation-Abstraction-Control (Представление-Абстракция-Контроллер),
Microkernel (микроядро),
Reflection (отражение).

14 of 59

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

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

Introduction

Шаблоны проектирования это шаблоны среднего уровня.

Design patterns are medium-scale patterns.

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

They are smaller in scale than architectural patterns, but are at a higher level than the programming language-specific idioms.

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

The application of a design pattern has no effect on the fundamental structure of a software system, but may have a strong influence on the architecture of a subsystem.

We group design patterns into categories of related pattems, in the same way as we did for architectural patterns:

1. Structural Decomposition.

This category includes patterns, that support a suitable decomposition of subsystems and complex components into cooperating parts.

The Whole-Part patter is the most general pattern we are aware of in this category.

It has wide applicability for structuring complex components.

2. Organization of Work.

This category comprises patterns that define how components collaborate together to solve a complex problem.

We describe

the Master-Slave pattern (245), which helps you to organize the computation of services for which fault tolerance or computational accuracy is required.

It also supports the splitting of services into independent parts and their execution in parallel.

3. Access Control.

Such patterns guard and control access to services or components.

We describe the Proxy pattern (263) here.

Proxy lets clients communicate with a representative of a component, rather than to the component itself.

4. Management.

This category includes patterns for handling homogenous collections of objects, services and components in their entirety.

We describe two patterns:

the Command Processor pattern (277) addresses the management and scheduling of user commands, while
the View Handler pattern (291) describes how to manage views in a software system.

5. Communication.

Patterns in this category help to organize communication between components.

Two patterns address issues of inter-process communication:

the Forwarder-Receiver pattern (307) deals with peer-to-peer communication, while
the Client Dispa1:cher-Server pattern (323) describes location-transparent communication in a Client-Server structure.
The Publisher-Subscriber pattern (339) helps with the task of keeping data consistent between cooperating components.

Publisher-Subscriber corresponds directly to the Observer pattern in [GHJV95].

We therefore only present the essence of this pattern, and focus on describing an important variant of Publisher-Subscriber, the Event Channel.

The design patterns included in this chapter only cover a small range of the problems that can occur when designing a software system.

The collection can and should be extended with further design patterns, for example those in [GHLJV95].

If more design patterns are added, it: may also become necessary to define new categories for organizing them.

We expand on this topic in Chapter 5, Pattern Systems.

An important property of all design patterns is that they are independent of a particular application domain.

They deal with the structuring of application functionality, not with the implementation of the application functionality itself.

Most design patterns are independent of a particular programming paradigm.

Usually they can be implemented easily in an object-oriented fashion, but all our design patterns are general enough to be adapted to more traditional programming practices, such as a procedural style.

15 of 59

Появление паттернов проектирования

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

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

«A Pattern Language: Towns, Buildings, Construction» (1977 г.),
«The Timeless Way of Building» (1979 г.).

1.1. О тенденциях в развитии паттернов в программировании

Идея паттернов проектирования первоначально возникла в архитектуре.

Архитектор Кристофер Александр написал две революционные книги, содержащие описание шаблонов в строительной архитектуре и городском планировании:

«A Pattern Language: Towns, Buildings, Contributions» (1977 г.),
«The Timeless Way of Building» (1979 г.).

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

В 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 (русскоязычный перевод книги — [GoF95]).

В этой книге описаны 23 паттерна проектирования.

Группа авторов этой книги известна под названием «Банда четырёх» (Gang of Four, часто сокращается, как GoF).

Эта книга и стала причиной роста популярности паттернов проектирования.

Таким образом, широкое использование паттернов в программировании началось из описания базовых 23-х шаблонов проектирования «Банды четырех».

Следующим шагом стало описание Мартином Фаулером Enterprise Patterns, где были раскрыты типичные решения при разработке корпоративных приложений, например, работа с базами данных, транзакциями и т.п.

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

(Рефакторинг — изменения внутреннего устройства программного кода без модификации его внешней функциональости. )

После начала акцентирования внимания на модульном тестировании (Unit Testing) появилось понятие тестируемости программного кода.

Все паттерны при этом были переосмыслены с позиций тестируемости.

При этом, например, оказалось, что

паттерн Singleton — это антипаттерн (см. пункт 3.5),

а Abstract Factory (см. пункт 3.1) вообще заменили IoC (Inversion of Control) контейнеры.

После выхода книги xUnit Test Patterns в 2008 году появилось несколько десятков паттернов тестирования.

16 of 59

Развитие идеи паттернов

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

Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. «Приемы объектно-ориентированного проектирования. Паттерны проектирования.» - СПб: Питер, 2001. - 386 с.

В этой книге описаны 23 паттерна проектирования.

17 of 59

Развитие идеи паттернов (2)

Мэри Шоу (Mary Shaw), Дэвид Гарлан (David Garlan), 1996 Опубликовали книгу «Архитектура программного обеспечения» – классификация архитектурных стилей;
Мартин Фаулер (Martin Fowler) опубликовал книгу «Архитектура корпоративных программных приложений» - типовые решения при разработке КИС,

Например, работа с базами данных, транзакциями и т.п.;

Джошуа Кериевски (Joshua Kerievsky) показал, как можно постоянным рефакторингом, руководствуясь базовыми принципами ООП, обеспечить эволюцию кода, перемещая его от одного паттерна к другому в зависимости от требований;
После начала активного использования модульного тестирования (Unit Testing) программного кода все паттерны при этом были переосмыслены с позиций тестируемости.

18 of 59

Martin C. Robert, Martin Micah Agile Principles, Patterns, and Practices in C#. - Prentice Hall, 2006, 768 p.

Роберт Мартин, Мика Мартин Принципы, паттерны и методики гибкой разработки на языке C#. - Пер. с англ. – СПб.: Символ-Плюс, 2011. – 768 с.

Robert C. Martin

President and Chief Executive Officer

Object Mentor

19 of 59

Понятие паттерна проектирования

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

Паттерны проектирования не зависят от выбора языка (хотя их реализации, зачастую, зависимы от языка программирования).
Идиомы — это паттерны, описывающие типичные решения на конкретном языке программирования.

1.3. Понятие паттерна проектирования

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

В объектно-ориентированном проектировании паттерну можно дать следующее определение.

Под паттерном проектирования (design pattern) будем понимать описание взаимодействия объектов и классов,

адаптированных для решения общей задачи проектирования в конкретном контексте [GoF95].

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

Также следует подчеркнуть отличие паттернов проектирования от идиом.

Идиомы — это паттерны, описывающие типичные решения на конкретном языке программирования, а паттерны проектирования не зависят от выбора языка (хотя их реализации, зачастую, зависимы от языка программирования).

20 of 59

Описание паттернов

В общем случае каждый паттерн состоит из таких составляющих:
Имя является уникальным идентификатором паттерна. Имена паттернов проектирования, описанных в [GoF], являются общепринятыми.

2. Задача описывает ситуацию, в которой можно применять паттерн.

3. Решения задачи проектирования в виде паттерна определяет общие функции каждого элемента дизайна и отношения между ними.

4. Результаты представляют следствия применения паттерна.

В общем случае каждый паттерн состоит из таких составляющих:

Имя является уникальным идентификатором паттерна.

Ссылка на него дает возможность описать задачу проектирования и подход к её решению.

Имена паттернов проектирования, описанных в [GoF95], являются общепринятыми, поэтому, например, могут использоваться в

проектной документации как ссылки на типичные архитектурные решения.

2. Задача описывает ситуацию, в которой можно применять паттерн.

При формулировке задачи паттерна важно описать, в каком контексте она возникает.

3. Решения задачи проектирования в виде паттерна определяет общие функции каждого элемента дизайна и отношения между ними.

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

4. Результаты представляют следствия применения паттерна.

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

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

Паттерн — это общее описание хорошего способа решения задачи.

Рядом с понятием «паттерн» часто фигурирует понятие «антипаттерн», или «антишаблон».

Антипаттерн — это часто повторяемое плохое решение, которое не рекомендуется использовать.

Цель паттерна — распознать возможность применения хорошего решения проблемы.

Цель антипаттерна — обнаружить плохую ситуацию и предложить подход к её устранению.

21 of 59

Классификация шаблонов �Gamma и др.

23 базовых шаблона
Шаблоны создания (Creational patterns) - builder, factory, prototype, singleton
Структурные шаблоны (Structural patterns) - adapter, bridge, composite, decorator, façade, flyweight, proxy
Шаблоны поведения (Behavioral patterns) - command, interpreter, iterator, mediator, memento, observer, state, strategy, template, visitor

22 of 59

Организация каталога шаблонов

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

быстрее освоить паттерны, описываемые в каталоге,
указывает направление поиска новых.

1.5. Организация каталога

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

В данном разделе описывается классификация, позволяющая ссылаться на семейства взаимосвязанных паттернов.

Она поможет быстрее освоить паттерны, описываемые в каталоге, и укажет направление поиска новых.

Мы будем классифицировать паттерны по двум критериям (табл. 1.1).

Первый - цель - отражает назначение паттерна.

В связи с этим выделяются

порождающие паттерны - связаны с процессом создания объектов;
структурные паттерны - имеют отношение к композиции объектов и классов;
паттерны поведения - характеризуют то, как классы или объекты взаимодействуют между собой.

Второй критерий - уровень - говорит о том, к чему обычно применяется паттерн:

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

Почти все паттерны в какой-то мере используют наследование.

Поэтому к категории «паттерны классов» отнесены только те, что сфокусированы лишь на отношениях между классами.

Обратите внимание: большинство паттернов действуют на уровне объектов.

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

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

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

Существуют и другие способы классификации паттернов.

Некоторые паттерны часто используются вместе.

Например, компоновщик применяется с итератором или посетителем.

Некоторыми паттернами предлагаются альтернативные решения.

Так, прототип нередко можно использовать вместо абстрактной фабрики.

Применение части паттернов приводит к схожему дизайну, хотя изначально их назначение различно.

Например, структурные диаграммы компоновщика и декоратора похожи.

Классифицировать паттерны можно и по их ссылкам (см. разделы «Родственные паттерны»).

На рис. 1.1 такие отношения изображены графически.

Ясно, что организовать паттерны проектирования допустимо многими способами.

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

23 of 59

Критерии классификации

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

Цель -- отражает назначение паттерна.
Уровень -- говорит о том, к чему обычно применяется паттерн.

1.5. Организация каталога

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

В данном разделе описывается классификация, позволяющая ссылаться на семейства взаимосвязанных паттернов.

Она поможет быстрее освоить паттерны, описываемые в каталоге, и укажет направление поиска новых.

Мы будем классифицировать паттерны по двум критериям (табл. 1.1).

Первый - цель - отражает назначение паттерна.

В связи с этим выделяются

порождающие паттерны - связаны с процессом создания объектов;
структурные паттерны - имеют отношение к композиции объектов и классов;
паттерны поведения - характеризуют то, как классы или объекты взаимодействуют между собой.

Второй критерий - уровень - говорит о том, к чему обычно применяется паттерн:

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

Почти все паттерны в какой-то мере используют наследование.

Поэтому к категории «паттерны классов» отнесены только те, что сфокусированы лишь на отношениях между классами.

Обратите внимание: большинство паттернов действуют на уровне объектов.

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

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

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

Существуют и другие способы классификации паттернов.

Некоторые паттерны часто используются вместе.

Например, компоновщик применяется с итератором или посетителем.

Некоторыми паттернами предлагаются альтернативные решения.

Так, прототип нередко можно использовать вместо абстрактной фабрики.

Применение части паттернов приводит к схожему дизайну, хотя изначально их назначение различно.

Например, структурные диаграммы компоновщика и декоратора похожи.

Классифицировать паттерны можно и по их ссылкам (см. разделы «Родственные паттерны»).

На рис. 1.1 такие отношения изображены графически.

Ясно, что организовать паттерны проектирования допустимо многими способами.

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

24 of 59

Классификация по целям паттернов проектирования

Порождающие паттерны (Creational Patterns).

Определяют способы создания объектов в системе.

Структурные паттерны (Structural Patterns).

Описывают способы построение сложных структур из классов и объектов.

Поведенческие паттерны (Behavioral Patterns).

Описывают способы взаимодействия между объектами.

Более детально рассмотрим паттерны проектирования, обобщив классификации, представленные в [DPWiki], [DPOverview]:

Основные паттерны (Fundamental Patterns).

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

2. Порождающие паттерны (Creational Patterns).

Определяют способы создания объектов в системе.

3. Структурные паттерны (Structural Patterns).

Описывают способы построение сложных структур из классов и объектов.

4. Поведенческие паттерны (Behavioral Patterns).

Описывают способы взаимодействия между объектами.

5. Паттерны параллельного программирования (Concurrency Patterns).

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

6. Паттерны МVС.

Включает такие паттерны как MVC (Model — View — Controller), MVP (Model - View - Presenter) и др.

7. Паттерны корпоративных систем (Enterprise Patterns).

Представляют решения для построения и интеграции больших корпоративных программных систем.

25 of 59

Классификация по уровням паттернов проектирования

Второй критерий: уровень - говорит о том, к чему обычно применяется паттерн:

уровень классов - описывают отношения между классами и их подклассами.

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

уровень объектов - описывают отношения между объектами, которые могут изменяться во время выполнения и потому более динамичны.

1.5. Организация каталога

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

В данном разделе описывается классификация, позволяющая ссылаться на семейства взаимосвязанных паттернов.

Она поможет быстрее освоить паттерны, описываемые в каталоге, и укажет направление поиска новых.

Мы будем классифицировать паттерны по двум критериям (табл. 1.1).

Первый - цель - отражает назначение паттерна.

В связи с этим выделяются

порождающие паттерны - связаны с процессом создания объектов;
структурные паттерны - имеют отношение к композиции объектов и классов;
паттерны поведения - характеризуют то, как классы или объекты взаимодействуют между собой.

Второй критерий - уровень - говорит о том, к чему обычно применяется паттерн:

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

Почти все паттерны в какой-то мере используют наследование.

Поэтому к категории «паттерны классов» отнесены только те, что сфокусированы лишь на отношениях между классами.

Обратите внимание: большинство паттернов действуют на уровне объектов.

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

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

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

Существуют и другие способы классификации паттернов.

Некоторые паттерны часто используются вместе.

Например, компоновщик применяется с итератором или посетителем.

Некоторыми паттернами предлагаются альтернативные решения.

Так, прототип нередко можно использовать вместо абстрактной фабрики.

Применение части паттернов приводит к схожему дизайну, хотя изначально их назначение различно.

Например, структурные диаграммы компоновщика и декоратора похожи.

Классифицировать паттерны можно и по их ссылкам (см. разделы «Родственные паттерны»).

На рис. 1.1 такие отношения изображены графически.

Ясно, что организовать паттерны проектирования допустимо многими способами.

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

26 of 59

Сводная таблица�паттернов проектирования

Цель Уровень	Порождающие паттерны	Структурные паттерны	Паттерны поведения
Класс	Factory Method	Adapter (класса)	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.1. Пространство паттернов проектирования

Цель Порождающие паттерны Структурные паттерны Паттерны поведения

Уровень

Класс Фабричный метод Адаптер (класса) Интерпретатор

Шаблонный метод

Объект Абстрактная фабрика

Одиночка

Прототип

Строитель

Адаптер (объекта)

Декоратор

Заместитель

Компоновщик

Мост

Приспособленец

Фасад

Итератор

Команда

Наблюдатель

Посетитель

Посредник

Состояние

Стратегия

Хранитель

Цепочка обязанностей

27 of 59

Список паттернов проектирования�(порождающие)

Factory Method (фабричный метод)

Определяет интерфейс для создания объектов, при этом выбранный класс инстанцируется подклассами

Abstract Factory (абстрактная фабрика)

Предоставляет интерфейс для создания семейств, связанных между собой, или независимых объектов, конкретные классы которых неизвестны

Singleton (одиночка)

Гарантирует, что некоторый класс может иметь только один экземпляр, и предоставляет глобальную точку доступа к нему

Prototype (прототип)

Описывает виды создаваемых объектов с помощью прототипа и создает новые объекты путем его копирования

Builder (строитель)

Отделяет конструирование сложного объекта от его представления, позволяя использовать один и тот же процесс конструирования для создания различных представлений.

1.4. Каталог паттернов проектирования

Каталог содержит 23 паттерна.

Ниже для удобства перечислены их имена и назначение.

В скобках после названия каждого паттерна указан номер страницы, откуда начинается его подробное описание.

Abstract Factory (абстрактная фабрика) (93)

Предоставляет интерфейс для создания семейств, связанных между собой, или независимых объектов, конкретные классы которых неизвестны.

Adapter (адаптер) (141)

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

Bridge (мост) (152)

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

Builder (строитель) (103)

Отделяет конструирование сложного объекта от его представления, позволяя использовать один и тот же процесс конструирования для создания различных представлений.

Chain of Responsibility (цепочка обязанностей) (217)

Можно избежать жесткой зависимости отправителя запроса от его получателя, при этом запросом начинает обрабатываться один из нескольких объектов. Объекты-получатели связываются в цепочку, и запрос передается по цепочке, пока какой-то объект его не обработает.

Command (команда) (226)

Инкапсулирует запрос в виде объекта, позволяя тем самым параметризовывать клиентов типом запроса, устанавливать очередность запросов, протоколировать их и поддерживать отмену выполнения операций.

Composite (компоновщик) (162)

Группирует объекты в древовидные структуры для представления иерархий типа «часть-целое». Позволяет клиентам работать с единичными объектами так же, как с группами объектов.

Decorator (декоратор) (173)

Динамически возлагает на объект новые функции. Декораторы применяются для расширения имеющейся функциональности и являются гибкой альтернативой порождению подклассов.

Facade (фасад) (183)

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

28 of 59

Список паттернов проектирования (структурные )

Adapter (адаптер)

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

Bridge (мост)

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

Decorator (декоратор)

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

1.4. Каталог паттернов проектирования

Каталог содержит 23 паттерна.

Ниже для удобства перечислены их имена и назначение.

В скобках после названия каждого паттерна указан номер страницы, откуда начинается его подробное описание.

Abstract Factory (абстрактная фабрика) (93)

Предоставляет интерфейс для создания семейств, связанных между собой, или независимых объектов, конкретные классы которых неизвестны.

Adapter (адаптер) (141)

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

Bridge (мост) (152)

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

Builder (строитель) (103)

Отделяет конструирование сложного объекта от его представления, позволяя использовать один и тот же процесс конструирования для создания различных представлений.

Chain of Responsibility (цепочка обязанностей) (217)

Можно избежать жесткой зависимости отправителя запроса от его получателя, при этом запросом начинает обрабатываться один из нескольких объектов. Объекты-получатели связываются в цепочку, и запрос передается по цепочке, пока какой-то объект его не обработает.

Command (команда) (226)

Инкапсулирует запрос в виде объекта, позволяя тем самым параметризо-вывать клиентов типом запроса, устанавливать очередность запросов, протоколировать их и поддерживать отмену выполнения операций.

Composite (компоновщик) (162)

Группирует объекты в древовидные структуры для представления иерархий типа «часть-целое». Позволяет клиентам работать с единичными объектами так же, как с группами объектов.

Decorator (декоратор) (173)

Динамически возлагает на объект новые функции. Декораторы применяются для расширения имеющейся функциональности и являются гибкой альтернативой порождению подклассов.

Facade (фасад) (183)

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

29 of 59

Список паттернов проектирования (структурные) (2)

Proxy (заместитель)

Подменяет другой объект для контроля доступа к нему

Facade (фасад)

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

Composite (компоновщик)

Группирует объекты в древовидные структуры для представления иерархий типа «часть-целое».
Позволяет клиентам работать с единичными объектами так же, как с группами объектов.

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

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

1.4. Каталог паттернов проектирования

Каталог содержит 23 паттерна.

Ниже для удобства перечислены их имена и назначение.

В скобках после названия каждого паттерна указан номер страницы, откуда начинается его подробное описание.

Abstract Factory (абстрактная фабрика) (93)

Предоставляет интерфейс для создания семейств, связанных между собой, или независимых объектов, конкретные классы которых неизвестны.

Adapter (адаптер) (141)

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

Bridge (мост) (152)

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

Builder (строитель) (103)

Отделяет конструирование сложного объекта от его представления, позволяя использовать один и тот же процесс конструирования для создания различных представлений.

Chain of Responsibility (цепочка обязанностей) (217)

Можно избежать жесткой зависимости отправителя запроса от его получателя, при этом запросом начинает обрабатываться один из нескольких объектов. Объекты-получатели связываются в цепочку, и запрос передается по цепочке, пока какой-то объект его не обработает.

Command (команда) (226)

Инкапсулирует запрос в виде объекта, позволяя тем самым параметризо-вывать клиентов типом запроса, устанавливать очередность запросов, протоколировать их и поддерживать отмену выполнения операций.

Composite (компоновщик) (162)

Группирует объекты в древовидные структуры для представления иерархий типа «часть-целое». Позволяет клиентам работать с единичными объектами так же, как с группами объектов.

Decorator (декоратор) (173)

Динамически возлагает на объект новые функции. Декораторы применяются для расширения имеющейся функциональности и являются гибкой альтернативой порождению подклассов.

Facade (фасад) (183)

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

30 of 59

Список паттернов проектирования (поведения)

Interpreter (интерпретатор)

Для заданного языка определяет представление его грамматики, а также интерпретатор предложений языка, использующий это представление

Template Method (шаблонный метод)

Определяет скелет алгоритма, перекладывая ответственность за некоторые его шаги на подклассы.
Позволяет подклассам переопределять шаги алгоритма, не меняя его общей структуры

Iterator (итератор)

Дает возможность последовательно обойти все элементы составного объекта, не раскрывая его внутреннего представления.

1.4. Каталог паттернов проектирования

Каталог содержит 23 паттерна.

Ниже для удобства перечислены их имена и назначение.

В скобках после названия каждого паттерна указан номер страницы, откуда начинается его подробное описание.

Abstract Factory (абстрактная фабрика) (93)

Предоставляет интерфейс для создания семейств, связанных между собой, или независимых объектов, конкретные классы которых неизвестны.

Adapter (адаптер) (141)

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

Bridge (мост) (152)

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

Builder (строитель) (103)

Отделяет конструирование сложного объекта от его представления, позволяя использовать один и тот же процесс конструирования для создания различных представлений.

Chain of Responsibility (цепочка обязанностей) (217)

Можно избежать жесткой зависимости отправителя запроса от его получателя, при этом запросом начинает обрабатываться один из нескольких объектов. Объекты-получатели связываются в цепочку, и запрос передается по цепочке, пока какой-то объект его не обработает.

Command (команда) (226)

Инкапсулирует запрос в виде объекта, позволяя тем самым параметризо-вывать клиентов типом запроса, устанавливать очередность запросов, протоколировать их и поддерживать отмену выполнения операций.

Composite (компоновщик) (162)

Группирует объекты в древовидные структуры для представления иерархий типа «часть-целое». Позволяет клиентам работать с единичными объектами так же, как с группами объектов.

Decorator (декоратор) (173)

Динамически возлагает на объект новые функции. Декораторы применяются для расширения имеющейся функциональности и являются гибкой альтернативой порождению подклассов.

Facade (фасад) (183)

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

31 of 59

Список паттернов проектирования (поведения) (2)

Command (команда)

Инкапсулирует запрос в виде объекта, позволяя тем самым параметризовывать клиентов типом запроса, устанавливать очередность запросов, протоколировать их и поддерживать отмену выполнения операций

Observer (наблюдатель)

Определяет между объектами зависимость типа один-ко-многим, так что при изменении состоянии одного объекта все зависящие от него получают извещение и автоматически обновляются

Visitor (посетитель)

Представляет операцию, которую надо выполнить над элементами объекта. Позволяет определить новую операцию, не меняя классы элементов, к которым он применяется.

1.4. Каталог паттернов проектирования

Каталог содержит 23 паттерна.

Ниже для удобства перечислены их имена и назначение.

В скобках после названия каждого паттерна указан номер страницы, откуда начинается его подробное описание.

Abstract Factory (абстрактная фабрика) (93)

Предоставляет интерфейс для создания семейств, связанных между собой, или независимых объектов, конкретные классы которых неизвестны.

Adapter (адаптер) (141)

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

Bridge (мост) (152)

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

Builder (строитель) (103)

Отделяет конструирование сложного объекта от его представления, позволяя использовать один и тот же процесс конструирования для создания различных представлений.

Chain of Responsibility (цепочка обязанностей) (217)

Можно избежать жесткой зависимости отправителя запроса от его получателя, при этом запросом начинает обрабатываться один из нескольких объектов. Объекты-получатели связываются в цепочку, и запрос передается по цепочке, пока какой-то объект его не обработает.

Command (команда) (226)

Инкапсулирует запрос в виде объекта, позволяя тем самым параметризо-вывать клиентов типом запроса, устанавливать очередность запросов, протоколировать их и поддерживать отмену выполнения операций.

Composite (компоновщик) (162)

Группирует объекты в древовидные структуры для представления иерархий типа «часть-целое». Позволяет клиентам работать с единичными объектами так же, как с группами объектов.

Decorator (декоратор) (173)

Динамически возлагает на объект новые функции. Декораторы применяются для расширения имеющейся функциональности и являются гибкой альтернативой порождению подклассов.

Facade (фасад) (183)

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

32 of 59

Список паттернов проектирования (поведения) (3)

Mediator (посредник)

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

Memento (хранитель)

Позволяет, не нарушая инкапсуляции, получить и сохранить во внешней памяти внутреннее состояние объекта, чтобы позже объект можно было восстановить точно в таком же состоянии.

Factory Method (фабричный метод) (111)

Определяет интерфейс для создания объектов, при этом выбранный класс инстанцируется подклассами.

Flyweight (приспособленец) (191)

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

Interpreter (интерпретатор) (236)

Для заданного языка определяет представление его грамматики, а также интерпретатор предложений языка, использующий это представление.

Iterator (итератор) (173)

Дает возможность последовательно обойти все элементы составного объекта, не раскрывая его внутреннего представления.

Mediator (посредник) (263)

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

Memento (хранитель) (272)

Позволяет, не нарушая инкапсуляции, получить и сохранить во внешней памяти внутреннее состояние объекта, чтобы позже объект можно было восстановить точно в таком же состоянии.

Observer (наблюдатель) (281)

Определяет между объектами зависимость типа один-ко-многим, так что при изменении состоянии одного объекта все зависящие от него получают извещение и автоматически обновляются.

Prototype (прототип) (121)

Описывает виды создаваемых объектов с помощью прототипа и создает новые объекты путем его копирования.

Proxy (заместитель) (203)

Подменяет другой объект для контроля доступа к нему.

Singleton (одиночка) (130)

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

State (состояние)(291)

Позволяет объекту варьировать свое поведение при изменении внутреннего состояния. При этом создается впечатление, что поменялся класс объекта.

Strategy (стратегия) (300)

Определяет семейство алгоритмов, инкапсулируя их все и позволяя подставлять один вместо другого. Можно менять алгоритм независимо от клиента, который им пользуется.

Template Method (шаблонный метод) (309)

Определяет скелет алгоритма, перекладывая ответственность за некоторые его шаги на подклассы. Позволяет подклассам переопределять шаги алгоритма, не меняя его общей структуры.

Visitor (посетитель) (314)

Представляет операцию, которую надо выполнить над элементами объекта. Позволяет определить новую операцию, не меняя классы элементов, к которым он применяется.

33 of 59

Список паттернов проектирования (5)

State (состояние)

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

Factory Method (фабричный метод) (111)

Определяет интерфейс для создания объектов, при этом выбранный класс инстанцируется подклассами.

Flyweight (приспособленец) (191)

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

Interpreter (интерпретатор) (236)

Для заданного языка определяет представление его грамматики, а также интерпретатор предложений языка, использующий это представление.

Iterator (итератор) (173)

Дает возможность последовательно обойти все элементы составного объекта, не раскрывая его внутреннего представления.

Mediator (посредник) (263)

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

Memento (хранитель) (272)

Позволяет, не нарушая инкапсуляции, получить и сохранить во внешней памяти внутреннее состояние объекта, чтобы позже объект можно было восстановить точно в таком же состоянии.

Observer (наблюдатель) (281)

Определяет между объектами зависимость типа один-ко-многим, так что при изменении состоянии одного объекта все зависящие от него получают извещение и автоматически обновляются.

Prototype (прототип) (121)

Описывает виды создаваемых объектов с помощью прототипа и создает новые объекты путем его копирования.

Proxy (заместитель) (203)

Подменяет другой объект для контроля доступа к нему.

Singleton (одиночка) (130)

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

State (состояние)(291)

Позволяет объекту варьировать свое поведение при изменении внутреннего состояния. При этом создается впечатление, что поменялся класс объекта.

Strategy (стратегия) (300)

Определяет семейство алгоритмов, инкапсулируя их все и позволяя подставлять один вместо другого. Можно менять алгоритм независимо от клиента, который им пользуется.

Template Method (шаблонный метод) (309)

Определяет скелет алгоритма, перекладывая ответственность за некоторые его шаги на подклассы. Позволяет подклассам переопределять шаги алгоритма, не меняя его общей структуры.

Visitor (посетитель) (314)

Представляет операцию, которую надо выполнить над элементами объекта. Позволяет определить новую операцию, не меняя классы элементов, к которым он применяется.

34 of 59

Список паттернов проектирования (поведения) (4)

Chain of Responsibility (цепочка обязанностей)

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

1.4. Каталог паттернов проектирования

Каталог содержит 23 паттерна.

Ниже для удобства перечислены их имена и назначение.

В скобках после названия каждого паттерна указан номер страницы, откуда начинается его подробное описание.

Abstract Factory (абстрактная фабрика) (93)

Предоставляет интерфейс для создания семейств, связанных между собой, или независимых объектов, конкретные классы которых неизвестны.

Adapter (адаптер) (141)

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

Bridge (мост) (152)

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

Builder (строитель) (103)

Отделяет конструирование сложного объекта от его представления, позволяя использовать один и тот же процесс конструирования для создания различных представлений.

Chain of Responsibility (цепочка обязанностей) (217)

Можно избежать жесткой зависимости отправителя запроса от его получателя, при этом запросом начинает обрабатываться один из нескольких объектов. Объекты-получатели связываются в цепочку, и запрос передается по цепочке, пока какой-то объект его не обработает.

Command (команда) (226)

Инкапсулирует запрос в виде объекта, позволяя тем самым параметризо-вывать клиентов типом запроса, устанавливать очередность запросов, протоколировать их и поддерживать отмену выполнения операций.

Composite (компоновщик) (162)

Группирует объекты в древовидные структуры для представления иерархий типа «часть-целое». Позволяет клиентам работать с единичными объектами так же, как с группами объектов.

Decorator (декоратор) (173)

Динамически возлагает на объект новые функции. Декораторы применяются для расширения имеющейся функциональности и являются гибкой альтернативой порождению подклассов.

Facade (фасад) (183)

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

35 of 59

36 of 59

Классификация архитектурных стилей Show&Garlan

Архитектура потоков данных
Независимые компоненты
Виртуальные машины
Репозиторные архитектуры
Уровневые архитектуры.

37 of 59

Архитектура потоков данных

Последовательные пакеты
Каналы и фильтры

Каждый процесс обработки данных проектируется независимо
Данные поступают, обрабатываются и передаются.

38 of 59

Архитектура каналов и фильтров

Обрабатывающие модули ждут данных, чтобы начать свою работу

39 of 59

Классификация архитектур Show&Garlan

Архитектура потоков данных

Последовательные пакеты
Каналы и фильтры

Независимые компоненты

Параллельно взаимодействующие процессы
Клиент-серверные системы
Системы, управляемые событиями

Виртуальные машины

Интерпретаторы
Системы, основанные на правилах

Репозиторные архитектуры

Базы данных
Гипертекстовые системы
Доски объявлений

Уровневые архитектуры

40 of 59

Архитектура независимых компонент

Состоит из компонент, работающих независимо и обменивающихся между собой информацией

Параллельно взаимодействующие процессы
Клиент-серверные системы
Системы, управляемые событиями.

41 of 59

Клиент-серверная архитектура

Серверы обслуживают клиентов с помощью запросов
Низкое сцепление между компонентами
«Узкий» интерфейс
Шаблон «Facade»

42 of 59

Шаблон «Фасад»

43 of 59

Архитектура библиотечной системы фильмов и фотографий

44 of 59

Архитектура параллельно взаимодействующих процессов

Параллельный запуск нескольких процессов (потоков, нитей)
Шаблон «Observer» (наблюдатель)

45 of 59

Шаблон «Наблюдатель»

46 of 59

Архитектура событийно-управляемых систем

Приложение состоит из набора компонент, каждый из которых находится в состоянии ожидания, пока не произойдет воздействующее на него событие
Если поведение описывается набором состояний –
Подходит Шаблон «State»

47 of 59

Шаблон «State»

48 of 59

Архитектура виртуальных машин

Рассматривает приложение, как программу, написанную на специальном языке
Если грамматика мала и скорость некритична – подходит Шаблон Interpreter

49 of 59

Репозиторные архитектуры

Виды репозиторных архитектур:

Базы данных
Гипертекстовые системы
Доски объявлений

Шаблон «Iterator»

50 of 59

Архитектура набора CASE-средств

51 of 59

Шаблон «Iterator»

52 of 59

Уровневые архитектуры

Уровень = Слой (Layer)
Видимость «сверху вниз»
Инкапсуляция внутренних слоев
Высокая степень автономности слоев

Количество уровней
Особенности реализации уровней.

53 of 59

Эталонная трехслойная модель

Слой представления (Presentation)
Слой предметной области или домен (Domain)
Источник данных (Data Source)

54 of 59

Преимущества «расслоения»

Отдельный слой можно воспринимать как единое самодостаточное целое, не особенно заботясь о наличии других)
Можно выбирать альтернативную реализацию базовых слоев
Зависимость между слоями можно свести к минимуму.
Каждый слой является удачным кандидатом на стандартизацию (например, TCP и
Созданный слой может служить основой для нескольких различных слоев более высокого уровня

Отдельный слой можно воспринимать как единое самодостаточное целое, не осо

бенно заботясь о наличии других слоев (скажем, для создание службы FTP необ

ходимо знать протокол TCP, но не тонкости Ethernet).

• Можно выбирать альтернативную реализацию базовых слоев (приложения FTP

способны работать без каких-либо изменений в среде Ethernet, по соединению

РРР или в любой другой среде передачи информации).

• Зависимость между слоями можно свести к минимуму. Так, при смене среды пере

дачи информации (при условии сохранения функциональности слоя IP) служба

FTP будет продолжать работать как ни в чем не бывало.

• Каждый слой является удачным кандидатом на стандартизацию (например, TCP и

IP — стандарты, определяющие особенности функционирования соответствую

щих слоев системы сетевых коммуникаций).

• Созданный слой может служить основой для нескольких различных слоев более

высокого уровня (протоколы TCP/IP используются приложениями FTP, telnet,

SSH и HTTP). В противном случае для каждого протокола высокого уровня при

шлось бы изобретать собственный протокол низкого уровня.

55 of 59

М. Фаулер. Архитектура корпоративных программных приложений

• "расслоение" приложения по уровням;

• структурирование логики предметной области;

• разработка пользовательского Web-интерфейса;

• связывание модулей, размещаемых в памяти (в частности, объектов), с реляционной базой данных;

• принципы распределения программных компонентов и данных.

56 of 59

Область знаний «проектирование ПО» в SWEBOK

Основы проектирования
Ключевые вопросы проектирования
Структура и архитектура ПО
Анализ качества и оценка результатов проектирования
Нотации проектирования ПО
Стратегии и методы проектирования ПО

57 of 59

3.2. Архитектурные стили

Архитектурный стиль определяет

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

Примеры:

Каналы и фильтры
Уровневые архитектуры
Данные-представления-обработка (MVC)
и т.д.

58 of 59

3.3. Шаблоны проектирования

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

59 of 59

Классификации архитектур (архитектурных стилей)

Gamma, Johnson, Helm, Vlissides

Эрик Брауде. Технология разработки программного обеспечения – СПб, Питер, 2004

Show, Garlan

Mary Shaw and David Garlan, Software Architecture -- Perspectives on an Emerging Discipline, Prentice Hall, 1996

Fowler

Мартин Фаулер. Архитектура корпоративных программных приложений.: — М.: Издательский дом "Вильямс", 2006.