![](/user_photo/2706_HbeT2.jpg)
- •1. Назначение языка
- •2. Способы использования языка
- •3. Нотация языка uml
- •Виды диаграмм uml
- •5. Диаграмма прецедентов (use case diagram)
- •6. Диаграмма классов (class diagram)
- •7. Диаграмма объектов (object diagram)
- •8. Диаграмма последовательностей (sequence diagram)
- •9. Диаграмма взаимодействия (кооперации, collaboration diagram)
- •10. Диаграмма состояний (statechart diagram)
- •11. Диаграмма активности (деятельности, activity diagram)
- •12. Диаграмма развертывания (deployment diagram)
- •13. Ооп и последовательность построения диаграмм
- •14. Отображение класса и его элементов на диаграмме uml
- •15. Способы использования объектов класса
- •16. Моделирование наследования в uml
- •17. Отношения между классами
- •18. Отношение зависимости между классами
- •19. Отношение ассоциации между классами
- •20. Композиция и агрегация классов
- •21. Сравнение диаграмм активностей и блок-схем
- •22. Моделирование процессов диаграммами активности
- •23. Моделирование операций диаграммами активности
- •24. Правила построения диаграммам активности
- •Составление перечня деятельностей в системе
- •Принятие решения о необходимости построения диаграммы деятельностей
- •25. Диаграмма кооперации
- •26. Диаграмма последовательностей как диаграмма взаимодействия
- •27. Диаграмма кооперации как альтернатива диаграмм последовательностей
- •28. Диаграмма кооперации как диаграмма взаимодействий объектов
- •29. Типы сообщений: синхронные, асинхронные и ответные, потерянные и найденные.
- •30. Уровни экземпляров и спецификации в диаграммах кооперации
- •31. Мультиобъекты, композитные и активные объекты в диаграммах кооперации.
- •32. Диаграммы взаимодействия с разветвленным потоком управления
- •33. Нефункциональные требования и их отображение на диаграммах прецедентов
- •34. Понятие эктора и отношения между экторами
- •35. Отношения включения и расширения между экторами
- •36. Причины использования прецедентов.
- •37. Прецеденты в прямом и обратном проектировании
- •38. Обзор case-средств для построения диаграмм uml
- •Visio поддерживает множество локальных языков
- •39. Критерии выделения прецедентов
- •40. Понятие шаблона проектирования
- •41. Основные шаблоны grasp
- •Information Expert (Информационный эксперт)
- •Indirection (Посредник)
- •42. Описание шаблонов проектирования GoF
- •43. Классификация шаблонов проектирования GoF
- •44. Структурные шаблоны проектирования
- •56. Понятие рефакторинга программ
- •57. Анти-шаблоны управления разработкой программ
- •Раздувание по (Software bloat): Разрешение последующим версиям системы требовать всё больше и больше ресурсов
- •58. Анти-шаблоны разработки программ
- •59. Анти-шаблоны в объектно-ориентированном программировании
- •60. Анти-шаблоны в программировании
- •61. Методологические анти-шаблоны
- •62. Анти-шаблоны управления конфигурацией
- •63. Примеры организационных анти-шаблонов
- •64. Социальные анти-шаблоны
- •Шаблоны параллельного программирования (Concurrency)
- •Другие типы шаблонов
- •66. Шаблон делегирования
- •Простой пример
- •67. Шаблон функционального дизайна
- •68. Неизменяемый объект (шаблон проектирования)
- •69. Интерфейс (шаблон проектирования)
- •70. Порождающие шаблоны проектирования
- •71. Абстрактная фабрика (шаблон проектирования)
- •72. Строитель (шаблон проектирования)
- •73. Фабричный метод (шаблон проектирования)
- •74. Отложенная инициализация (шаблон проектирования)
- •75. Объектный пул (шаблон проектирования)
- •76. Прототип (шаблон проектирования)
- •77. Получение ресурса есть инициализация (шаблон проектирования)
- •78. Одиночка (шаблон проектирования)
- •79. Структурные шаблоны
- •80. Адаптер (шаблон проектирования)
- •81. Мост (шаблон проектирования)
- •82. Компоновщик (шаблон проектирования)
- •83. Декоратор (шаблон проектирования)
- •84. Фасад (шаблон проектирования)
- •85. Приспособленец (шаблон проектирования)
- •86. Заместитель (шаблон проектирования)
- •87. Поведенческие шаблоны
- •88. Цепочка ответственности (шаблон проектирования)
- •89. Команда (шаблон проектирования)
- •90. Интерпретатор (шаблон проектирования)
- •91. Итератор (шаблон проектирования)
- •92. Посредник (шаблон проектирования)
- •93. Хранитель (шаблон проектирования)
- •94. Наблюдатель (шаблон проектирования)
- •95. Состояние (шаблон проектирования)
- •96. Стратегия (шаблон проектирования)
- •97. Шаблоны параллельного программирования Шаблоны параллельного программирования (Concurrency)
- •Пример реализации Пример c#
- •Следствия
- •98. Модель-представление-контроллер (шаблон проектирования)
- •99. Технология использования шаблонов проектирования
96. Стратегия (шаблон проектирования)
поведенческий шаблон проектирования, предназначенный для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости. Это позволяет выбирать алгоритм путем определения соответствующего класса. Шаблон Strategy позволяет менять выбранный алгоритм независимо от объектов-клиентов, которые его используют.
Задача
Выбор алгоритма, который следует применить, в зависимости от типа выдавшего запрос клиента или обрабатываемых данных. Если используется правило, которое не подвержено изменениям, нет необходимости обращаться к шаблону «стратегия».
Мотивы
Программа должна обеспечивать различные варианты алгоритма или поведения
Нужно изменять поведение каждого экземпляра класса
Необходимо изменять поведение объектов на стадии выполнения
Введение интерфейса позволяет классам-клиентам ничего не знать о классах, реализующих этот интерфейс и инкапсулирующих в себе конкретные алгоритмы
Способ решения
Отделение процедуры выбора алгоритма от его реализации. Это позволяет сделать выбор на основании контекста.
Участники
Класс Strategy определяет как будут использоваться различные алгоритмы.
Конкретные классы ConcreteStrategy реализуют эти различные алгоритмы.
Класс Context использует конкретные классы ConcreteStrategy посредством ссылки на конкретный тип абстрактного класса Strategy. Классы Strategy и Context взаимодействуют с целью реализации выбранного алгоритма (в некоторых случаях классу Strategy требуется посылать запросы классу Context). Класс Context пересылает классу Strategy запрос, поступивший от его класса-клиента.
Следствия
Шаблон Strategy определяет семейство алгоритмов.
Это позволяет отказаться от использования переключателей и/или условных операторов.
Вызов всех алгоритмов должен осуществляться стандартным образом (все они должны иметь одинаковый интерфейс).
Реализация
Класс, который использует алгоритм (Context), включает абстрактный класс (Strategy), обладающий абстрактным методом, определяющим способ вызова алгоритма. Каждый производный класс реализует один требуемый вариант алгоритма.
Замечание: метод вызова алгоритма не должен быть абстрактным, если требуется реализовать некоторое поведение, принимаемое по умолчанию.
using System;
namespace DesignPatterns.Behavioral.Strategy
{
/// <summary>
/// Интерфейс «Стратегия» определяет функциональность (в данном примере это метод
/// <see cref="Algorithm">Algorithm</see>), которая должна быть реализована
/// конкретными классами стратегий. Другими словами, метод интерфейса определяет
/// решение некой задачи, а его реализации в конкретных классах стратегий определяют,
/// КАК, КАКИМ ПУТЁМ эта задача будет решена.
/// </summary>
public interface IStrategy
{
void Algorithm();
}
/// <summary>
/// Первая конкретная реализация-стратегия.
/// </summary>
public class ConcreteStrategy1 : IStrategy
{
public void Algorithm()
{
Console.WriteLine("Выполняется алгоритм стратегии 1.");
}
}
/// <summary>
/// Вторая конкретная реализация-стратегия.
/// Реализаций может быть сколько угодно много.
/// </summary>
public class ConcreteStrategy2 : IStrategy
{
public void Algorithm()
{
Console.WriteLine("Выполняется алгоритм стратегии 2.");
}
}
/// <summary>
/// Контекст, использующий стратегию для решения своей задачи.
/// </summary>
public class Context
{
/// <summary>
/// Ссылка на интерфейс <see cref="IStrategy">IStrategy</see>
/// позволяет автоматически переключаться между конкретными реализациями
/// (другими словами, это выбор конкретной стратегии).
/// </summary>
private IStrategy _strategy;
/// <summary>
/// Конструктор контекста.
/// Инициализирует объект стратегией.
/// </summary>
/// <param name="strategy">
/// Стратегия.
/// </param>
public Context(IStrategy strategy)
{
_strategy = strategy;
}
/// <summary>
/// Метод для установки стратегии.
/// Служит для смены стратегии во время выполнения.
/// В C# может быть реализован также как свойство записи.
/// </summary>
/// <param name="strategy">
/// Новая стратегия.
/// </param>
public void SetStrategy(IStrategy strategy)
{
_strategy = strategy;
}
/// <summary>
/// Некоторая функциональность контекста, которая выбирает
/// стратегию и использует её для решения своей задачи.
/// </summary>
public void ExecuteOperation()
{
_strategy.Algorithm();
}
}
/// <summary>
/// Класс приложения.
/// В данном примере выступает как клиент контекста.
/// </summary>
public static class Program
{
/// <summary>
/// Точка входа в программу.
/// </summary>
public static void Main()
{
// Создём контекст и инициализируем его первой стратегией.
Context context = new Context(new ConcreteStrategy1());
// Выполняем операцию контекста, которая использует первую стратегию.
context.ExecuteOperation();
// Заменяем в контексте первую стратегию второй.
context.SetStrategy(new ConcreteStrategy2());
// Выполняем операцию контекста, которая теперь использует вторую стратегию.
context.ExecuteOperation();
}
}
}