Low Coupling - Слабая связанность.

ДГИ. Шаблоны проектирования»

24.Поведенческие шаблоны. Strategy

25.Поведенческие шаблоны. Observer

26.Поведенческие шаблоны. Iterator

27.Поведенческие шаблоны. Chain of Responsibility

28.Поведенческие шаблоны. Mediator

29.Поведенческие шаблоны. Template Method

30.Архитектурные шаблоны. Классификация

31.Архитектурные шаблоны. Клиент-серверные системы

32.Архитектурные шаблоны. Многоуровневые системы

33.Архитектурные шаблоны. Репозиторий

34.Архитектурные шаблоны. Поток данных

35.Архитектурные шаблоны. Централизованное управление

36.Архитектурные ш-ны. Управление, основанное на событиях

37.Архитектурные шаблоны. Active Record

38.Архитектурные шаблоны. Unit of Work

39.Архитектурные шаблоны. Lazy Load

40.Архитектурные шаблоны. Identity Map

41.Архитектурные шаблоны. Data Access Object

42.ШП пользовательского интерфейса. Model-View-Controller

43.ШП пользовательского интерфейса. Document-View

44.ШП пользовательского интерфейса. Model-View-Presenter

45.ШП пользовательского интерфейса. Model-View-ViewModel

46.Антишаблоны

Понятие ШП. Средства описания ШП.

Строгого определения ШП нет, есть описательное.

ШП(англ. design pattern)  — это многократно используемые решения широко распространенных проблем, возникающих при разработке ПО.

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

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

Смысл Ш - предложить решение определён. з-чи в конкретном контексте.

Описание шаблонов:

Обычно шаблон описывается по следующей схеме:

· имя шаблона, под к-рым он широко известен. Если у Ш несколько имен, то они тоже приводятся. Сославшись на имя, можем сразу описать проблему проек-тирования, ее решения и их последствия. Присваивание паттернам имен позво-ляет проектировать на более высоком уровне абстракции;

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

· краткое изложение рассуждений, приводящих или к формулированию общего решения, или к выводу о его неприменимости;

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

· последствия, хорошие и плохие, как рез-т использования данного реш-ия проблемы. Рез-ты - это следствия применения паттерна и разн. рода компромиссы. Хотя при описании проектных реш-ий о последствиях часто не упоминают, знать о них н-мо, чтобы можно было выбрать м-ду различными вариантами и оценить преимущ-ва и недост-ки данного паттерна (выбор языка, реализация, влияние на степень гибкости, расширяемости и переносимости сис-мы).;

· перечень ШП, связанных с данным Ш (повторяемость).

Достоинства ШП:

· обобщение опыта экспертов и доступное его изложение;

· формирование профессиональной терминологии;

· экономия времени на поиск решения.

Недостаток ШП – использование ШП начинающими программистами подавляет их мышление.

История развития ШП. Классификация ШП.

 История развития ШП:

1. 1970-е гг. архитектор Кристофер Александр составил набор Ш для проектирования зданий и городов.

2. 1987 г. – Кент Бэк и Вард Каннигем применили Ш Александра для разработки графич. оболочек на языке Smalltalk.

3. 1988 г. – Эрих Гамма приступил к написанию докторской дис-ции по перенесению эт. методики на разработку программ в целом.

4. 1989-91 гг. – Джеймс Коплин разрабатывает идиомы для программирования на С++.

5. 1991 г. – Э.Гамма, Ричард Хелм, Ральф Джонсон и Джон Влиссидс («Банда четырёх» - Gang of Four - GoF) публик-т книгу «Design Patterns – Elements of Reusable Object-Oriented Software». В этой книге описаны 23 шаблона проектирования.

Классификация ШП:

· GRASP

- ш-ны распределения ответственности

ü GRASP(9 ш-нов):

Ø Information Expert

Ø Creator

Ø Controller

Ø Low Coupling

Ø High Cohesion

Ø Polymorphism

Ø Pure Fabrication

Ø Indirection

Ø Protected Variations

ü General

ü Responsibility

ü Assignment

ü Software

ü Patterns

· GoF[клас-ция по решаемым задачам]

- Структурные ш-ны (Structural):Адаптер, Компоновщик (Composite), Декоратор, Мост (Bridge). (как задать посредника для реш-ия з-чи)

- Порождающие ш-ны (Creational):Фабричный метод (Factory method), Строитель (Builder), Одиночка (Singleton). (з-чи на созд-ие об-в)

- Архитектурные ш-ны

- Поведенческие шаблоны(Behavioral):Интерпретатор, Итератор (организуют действия в иерархию).

- MVC, Enterprise и Антишаблоны

GRASP. Information Expert

GRASP (General Responsibility Assignment Software Patterns — общие образцы распределения обязанностей) — паттерны, используемые в ООП для решения общих задач по назначению обязанностей классам и объектам.

Information Expert - Информационный эксперт

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

Решение:Назначить обязанность аккумуляции информации, расчета и т. п. некоему классу (информационному эксперту), обладающему необходимой информацией.

Рекомендации:Информационным экспертом м. б. не один класс, а н-ко.

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

Недостатки:Если объект, обладающий наиболее полной информацией, будет отвечать и за сохранение этой информации в базе данных, то получится, что логика приложения (моделирование продажи) и логика связи с базой данных "помещаются" в один класс (нарушение принципа разделения обязанностей основных объектов системы, и, кроме того, логика связи с базой данных будет дублироваться во многих других классах.

-----------------------------------------------------------------------------------------

Шаблон Information Expert определяет базовый принцип назначения обязанностей. Он утверждает, что обязанности должны быть назначены объекту, который владеет максимумом необходимой информации для выполнения обязанности. Такой объект называется информационным экспертом. Возможно, этот шаблон является самым очевидным из девяти, но вместе с тем и самым важным.

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

GRASP. Creator

GRASP (General Responsibility Assignment Software Patterns — общие образцы распределения обязанностей) — паттерны, используемые в ООП для решения общих задач по назначению обязанностей классам и объектам.

Creator - Создатель

Проблема: "Кто" должен отвечать за создание экземпляров класса.

Решение: Назначить классу В обязанность создавать об-ты др. класса А

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

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

Недостатки Если процедура создания объекта достаточно сложная (например выполняется на основе некоего внешнего условия), логично использовать паттерн "Абстрактная Фабрика", т. е., делегировать обязанность создания обьектов специальному классу.

----------------------------------------------------------------------------------------------

Паттерн Creator решает, кто должен создавать объект. Фактически, это применение шаблона Information Expert к проблеме создания объектов. Более конкретно, нужно назначить классу B обязанность создавать экземпляры класса A, если выполняется как можно больше из следующих условий:

• Класс B содержит или агрегирует объекты A.
• Класс B записывает экземпляры объектов A.
• Класс B активно использует объекты A
• Класс B обладает данными инициализации для объектов A.

Альтернативой создателю является образец Фабрика. В этом случае создание объектов концентрируется в отдельном классе.

GRASP. Controller

GRASP (General Responsibility Assignment Software Patterns — общие образцы распределения обязанностей) — паттерны, используемые в ООП для решения общих задач по назначению обязанностей классам и объектам.

Controller - Контроллер

Отвечает за обработку запросов нашей сис-мы.

К-ры м.б. унифицированные (обработка данных не зависит от того, откуда пришёл запрос).

Проблема: "Кто" должен отвечать за обраб-ку вход-х системных событий?

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

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

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

 Недостатки: Контроллер может оказаться перегружен.

-----------------------------------------------------------------------------------------------

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

Иногда класс-контроллер представляет всю систему в целом, корневой объект, устройство или важную подсистему (внешний контроллер).

GRASP. Low Coupling

GRASP (General Responsibility Assignment Software Patterns — общие образцы распределения обязанностей) — паттерны, используемые в ООП для решения общих задач по назначению обязанностей классам и объектам.

Low Coupling - Слабая связанность.

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

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

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

Пример: Необходимо создать экземпляр класса "Платеж". В предметной области регистрация объекта "Платеж" выполняется объектом "Регистрация" (ведется рестр). Ниже приводятся 2 способа создания экземпляра класса "Платеж". Верхний рисунок - с использованием паттерна "Создатель", нижний - с использованием "Низкая связанность". Последний способ обеспечивает более низкую степень связывания.

 -------------------------------------------------------------------------------------------------

Low Coupling — это принцип, который позволяет распределить обязанности между объектами таким образом, чтобы степень связанности между системами оставалась низкой. Степень связанности (coupling) — это мера, определяющая, насколько жестко один элемент связан с другими элементами, либо каким количеством данных о других элементах он обладает. Элемент с низкой степенью связанности (или слабым связыванием) зависит от не очень большого числа др-х элементов и имеет следующие св-ва:

• Малое число зависимостей между классами (подсистемами).
• Слаб. зав-сть одного кл-са (подсис-мы) от изм-ний в др. кл-се (подс-ме).
• Высокая степень повторного использования подсистем.

GRASP. High Cohesion

GRASP (General Responsibility Assignment Software Patterns — общие образцы распределения обязанностей) — паттерны, используемые в ООП для решения общих задач по назначению обязанностей классам и объектам.