Design Patterns Mikhail Karpuk Software developer Itransition training

www.itransition.com
Page
Содержание
Введение
GoF patterns
MVC & MVP
Antipatterns

www.itransition.com
Page
Зачем это надо?
Чтобы не решать каждую задачу с нуля
Использовать проверенные временем решения
Заранее представлять последствия выбора того или иного варианта
Проектировать с учетом будущих изменений
Писать понятный и компактный код, который легко можно будет использовать повторно

www.itransition.com
Page
Что это такое?
Кристофер Александр: «Любой паттерн описывает задачу, которая снова и снова возникает в нашей работе, а также принцип ее решения, причем таким образом, что это решение можно использовать миллион раз, ничего не изобретая заново»
Это не кусок кода, класс или dll
Это идея, метод решения, общий подход к целому классу задач, постоянно встречающихся на практике

www.itransition.com
Page
Описание паттерна
Имя (имена)
Задача (когда применять паттерн)
Решение
Результаты (следствия и компромиссы)

www.itransition.com
Page
Null Value pattern
В некоторых ситуациях объект не может быть создан или не должен ничего делать.
Постоянные проверки сильно загромождают код и могут привести к ошибкам (Copy/Paste anti pattern)

www.itransition.com
Page
Результаты
Упрощение кода
Унификация вызовов
Уменьшение количества ошибок

www.itransition.com
Page
GoF patterns
Порождающие паттерны
Структурные паттерны
Паттерны поведения
(Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides)

www.itransition.com
Page
Порождающие паттерны
Обеспечивают независимость системы от процесса создания новых сущностей
Singleton
Abstract Factory

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

www.itransition.com
Page
Пример кода
public class Singleton
{
private static readonly Singleton singleton = new Singleton();
private Singleton()
{
// Note private constructor
}
public static Singleton GetSingleton()
{
return singleton;
}
public void SomeFunction() { }
}
static void Main()
{
Singleton.GetSingleton().SomeFunction();
}

www.itransition.com
Page
Abstract Factory (Kit)
Предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов, не специфицируя конкретных классов
Позволяет легко перейти на использование другого семейства
Добавление новых объектов в семейство затруднено

www.itransition.com
Page
Пример
public class ToolFactory
{
private ToolFactory(){}
public static ToolFactory GetFactory()
{
//… - Singleton
}
public ButtonTool CreateButtonTool(Tool tool, EventHandler toolClickHandler)
{
//Create Button Tool, add handler, set icon, caption, etc
}
public ButtonTool CreateStateButtonTool(Tool tool)
{
//Create Button Tool , caption, etc
}
}

www.itransition.com
Page
Паттерн Abstract Factory в действии
Public class SingleClickButtonTool : ButtonTool
{
private bool inHandler = false;
private EventHandler handler;
public SingleClickButtonTool (EventHandler handler)
OnButtonClick()
{
if (inHandler){return;}
inHandler = true;
try
{
handler.Invoke();
}
finally
{
inHandler = false;
}
}
}

www.itransition.com
Page
Структурные паттерны
Определяют, как классы и объекты группируются в более сложные структуры
Adapter
Facade
Proxy
Composite

www.itransition.com
Page
Adapter (Wrapper)
Преобразует интерфейс одного класса к интерфейсу, ожидаемому клиентом

Решение - множественное наследование

Решение - использовать композицию объектов

www.itransition.com
Page
Пример кода
public class TextControlAdapter : BaseUserControl
{
TextControl innerControl; String rtfText;
public String RtfText
{
get
{
if (innerControl.Loaded) {return innerControl.Rtf;}
else {return rtfText;}
}
set
{
if (innerControl.Loaded) {innerControl.Rtf = value;}
else {rtfText = value;}
}
}
public TextControlAdapter()
{
innerControl = new TextControl();
}
}

www.itransition.com
Page
Facade
Определяет интерфейс более высокого уровня
Скрывает ненужные связи и зависимости
Упрощает использование подсистемы

www.itransition.com
Page
Результат
Фасад переадресует запросы клиента классам системы, сами классы не «знают» о существовании фасада
Не нужно вникать во все тонкости и нюансы системы
Фасад не закрывает доступ к элементам системы, при необходимости можно использовать систему и в обход фасада

www.itransition.com
Page
Proxy (Surrogate)
Является суррогатом другого объекта и контролирует доступ к нему
«Создает тяжелые объекты только по требованию»

www.itransition.com
Page
Пример кода
public class Graphic
{
public virtual void Draw(Point point)
{
//…
}
}
public class Image : Graphic
{
public Image(string fileName)
{
//Load image from file
}
public override void Draw(Point point){…}
}

www.itransition.com
Page
Использование прокси
public class ImageProxy : Graphic
{
private Image image;
private string fileName;
public void ImageProxy(string fileName)
{
this.fileName = fileName;
}
public void Draw(Point point)
{
if (image == null)
image = new Image(fileName);
image.Draw(point);
}
}
public class TextDocument
{
//…
this.Inset(new ImageProxy(“TestImage.png”));
}

www.itransition.com
Page
Composite
Компонует объекты в древовидные структуры
Позволяет единообразно трактовать индивидуальные и составные объекты

www.itransition.com
Page
Пример кода
public class Equipment
{
private double netPrice; //Labor, $
public Equipment GetParent(){…}
public Equipment[] GetParts(){…}
public void AddPart(Equipment part){…}
public void RemovePart(Equipment part){…}
public virtual double GetPrice()
{
double amount = netPrice;
foreach(Equipment part in GetParts())
{
amount += part.GetPrice();
}
}
//…
}

www.itransition.com
Page
Паттерны поведения
Инкапсулируют поведение и связи между объектами
Strategy
Template method
Mediator

www.itransition.com
Page
Strategy (Policy)
Определяет семейство алгоритмов и делает их взаимозаменяемыми
Позволяет изменять алгоритмы независимо от клиентов, их использующих
Значительно упрощает добавление новых вариантов поведения

www.itransition.com
Page
Пример кода
public class CalculationStrategy
{
//…
public virtual double GetPrice(ArrayList priceItems){…}
}
public class RoundPriceStrategy : CalculationStrategy
{
int roundTo;
public RoundPriceStrategy Current(roundTo){… //Singleton}
public override double GetPrice(ArrayList priceItems){…}
}
public class LockPriceStrategy : CalculationStrategy
{
double totalAmount;
public LockPriceStrategy Current(totalAmount){… //Singleton}
public override double GetPrice(ArrayList priceItems){…}
}

www.itransition.com
Page
Использование стратегий
public class MainForm
{
//…
OnLockPriceChecked()
{
pricesTable.CalculationStrategy = LockPriceStrategy.Current(totalAmount);
}
OnRoundPriceChecked()
{
pricesTable.CalculationStrategy = RoundPriceStrategy.Current(roundTo);
}
}

www.itransition.com
Page
Template method
Определяет основу алгоритма
Позволяет подклассам переопределять отдельные шаги алгоритма, не меняя структуры
Унифицирует поведение, позволяет легко изменять детали в каждом конкретном случае.

www.itransition.com
Page
Пример кода
public class BaseForm
{
public void CloseForm()
{
bool sureToClose = ConfirmClose();
if (!sureToClose) {return;}
bool saved = Save();
if (saved) {this.Close();}
}
protected virtual bool ConfirmClose() {return true;}
protected virtual bool Save() {return true;}
}

www.itransition.com
Page
Продолжение примера
public class MainForm : BaseForm
{ //…
protected override Save()
{
bool saved = true;
if (this.Modified && ShowSaveQuestion())
{
try{SaveData();}
catch(Exception exception)
{
ProcessException(exception); //e.g. show message
saved = false;
}
}
return saved;
}
}

www.itransition.com
Page
Mediator
Обеспечивает слабую связанность системы, избавляет объекты от необходимости явно ссылаться друг на друга
Вместо многочисленных связей друг на друга все объескты системы хранят ссылку только на посредника

www.itransition.com
Page
Например
Взаимодействие модулей системы
Нет нужды разбираться в хитросплетениях системы.
Упрощен перенос методов между модулями
Возможность добавления/удаления модулей

www.itransition.com
Page
Результаты
Выносит взаимодействие между объектами в отдельный класс (легко изменять)
Преобразует связь много-ко-многим в один-ко-многим (просто понять и поддерживать)

www.itransition.com
Page
MVC – Model-View-Controller
Отделяет вид от модели, устанавливая между ними протокол взаимодействий
Позволяет организовать различные представления одних и тех же данных

www.itransition.com
Page
MVP – Model-View-Presenter
Смысл – тот же, что и у MVC (отделить данные от представления)
Ориентируется на современные контролы, которые сами обрабатывают системные события
Основное отличие – View само ловит события и перенаправляет классу Presenter, который решает, что с этим делать (в MVC события ловит Controller)

www.itransition.com
Page
Пример кода
public class Presenter
{...
public Presenter(IView view, IModel model)
{
this.view = view;
this.model = model;
SubscribeToViewEvents();
LoadViewFromModel();
}
}

www.itransition.com
Page
Результаты
Вынос поведения в отдельный класс – упрощает понимание кода
Позволяет вызывать события и моделировать различные ситуации независимо от GUI – полезно как при тестировании, так и при изменеии представления

www.itransition.com
Page
Antipatterns
Описывают наиболее распространенные недостатки (что плохо и почему это плохо)
Как с этим бороться (refactoring)
Как выглядит приемлемое решение (когда стоит останавливаться)

www.itransition.com
Page
Patterns vs. AntiPatterns

www.itransition.com
Page
The Blob
Огромный класс, содержащий тучу методов, относящихся к логически разным объектам.
Невозможность повторного использования
Модификация крайне затруднена, так как приходится следить за консистентностью большого количества данных
Да и вообще нарушает принципы ООП

www.itransition.com
Page
Poltergeist
Много мелких, перекрывающих друг друга классов
Классы имеют ограниченное использование
Большое количество связей – усложняет понимание и использование
Низкая производительность, неожиданные эффекты

www.itransition.com
Page
Исправление
Удалить ненужные, несущественные классы
Перегруппировать в более крупные связные классы

www.itransition.com
Page
Lava Flow
Код, который никто не понимает
Недокументированный код
Код, который невозможно тестировать
Автор кода давно отсутствует на проекте

www.itransition.com
Page
Как бороться
Не допускать (писать понятный, структурированный код и комментарии)
Не допускать (документировать требования)
Стиснуть зубы, разобраться и рефакторить

www.itransition.com
Page
Golden Hammer
Использование одного и того же решения всюду, где только можно и даже там, где нельзя
Игнорирование новых разработок
Решение:
Искать наиболее подходящие решения для данного конкретного случая

www.itransition.com
Page
Input Kludge
Возможность ввода данных, несоответствующих контексту
Возможность сохранения некорректных данных
Результат – «падения» и непредсказуемая работа
Решение:
Проверка всех входных данных на разных уровнях (DB, GUI)

www.itransition.com
Page
Refactoring
Это процесс систематического изменения программной системы, при котором внешнее поведение кода неизменно, но улучшается его внутренняя структура.
Это непрерывное приведение кода и комментариев в порядок.
Постоянный процесс, неотделимый от процесса разработки.
Мартин Фаулер «Рефакторинг».