Design Patterns Mikhail Karpuk Software developer Itransition training

Design Patterns Mikhail Karpuk Software developer Itransition training courses

www. itransition. co m Page 2 Содержание Введение Go. F patterns MVC & MVP Antipatterns

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

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

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

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

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

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

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

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

www. itransition. co m Page 14 Пример кода public class Singleton { private static readonly Singleton singleton = new Singleton(); private Singleton() { // Note private constructor } public static Singleton Get. Singleton() { return singleton; } public void Some. Function() { } } static void Main() { Singleton. Get. Singleton(). Some. Function(); }

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

www. itransition. co m Page 18 Пример public class Tool. Factory { private Tool. Factory(){} public static Tool. Factory Get. Factory() { //… — Singleton } public Button. Tool Create. Button. Tool(Tool tool, Event. Handler tool. Click. Handler) { //Create Button Tool, add handler, set icon, caption, etc } public Button. Tool Create. State. Button. Tool(Tool tool) { //Create Button Tool , caption, etc } }

www. itransition. co m Page 19 Паттерн Abstract Factory в действии Public class Single. Click. Button. Tool : Button. Tool { private bool in. Handler = false; private Event. Handler handler; public Single. Click. Button. Tool (Event. Handler handler) On. Button. Click() { if (in. Handler){return; } in. Handler = true; try { handler. Invoke(); } finally { in. Handler = false; } } }

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

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

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

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

www. itransition. co m Page 25 Пример кода public class Text. Control. Adapter : Base. User. Control { Text. Control inner. Control; String rtf. Text; public String Rtf. Text { get { if (inner. Control. Loaded) {return inner. Control. Rtf; } else {return rtf. Text; } } set { if (inner. Control. Loaded) {inner. Control. Rtf = value; } else {rtf. Text = value; } } } public Text. Control. Adapter() { inner. Control = new Text. Control(); } }

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

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

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

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

www. itransition. co m Page 32 Использование прокси public class Image. Proxy : Graphic { private Image image; private string file. Name; public void Image. Proxy(string file. Name) { this. file. Name = file. Name; } public void Draw(Point point) { if (image == null) image = new Image(file. Name); image. Draw(point); } } public class Text. Document { //… this. Inset(new Image. Proxy(“Test. Image. png”)); }

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

www. itransition. co m Page 35 Пример кода public class Equipment { private double net. Price; //Labor, $ public Equipment Get. Parent(){…} public Equipment[] Get. Parts(){…} public void Add. Part(Equipment part){…} public void Remove. Part(Equipment part){…} public virtual double Get. Price() { double amount = net. Price; foreach(Equipment part in Get. Parts()) { amount += part. Get. Price(); } } //… }

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

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

www. itransition. co m Page 39 Пример кода public class Calculation. Strategy { //… public virtual double Get. Price(Array. List price. Items){…} } public class Round. Price. Strategy : Calculation. Strategy { int round. To; public Round. Price. Strategy Current(round. To){… //Singleton} public override double Get. Price(Array. List price. Items){…} } public class Lock. Price. Strategy : Calculation. Strategy { double total. Amount; public Lock. Price. Strategy Current(total. Amount){… //Singleton} public override double Get. Price(Array. List price. Items){…} }

www. itransition. co m Page 40 Использование стратегий public class Main. Form { //… On. Lock. Price. Checked() { prices. Table. Calculation. Strategy = Lock. Price. Strategy. Current(total. Amount); } On. Round. Price. Checked() { prices. Table. Calculation. Strategy = Round. Price. Strategy. Current(round. To); } }

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

www. itransition. co m Page 43 Пример кода public class Base. Form { public void Close. Form() { bool sure. To. Close = Confirm. Close(); if (!sure. To. Close) {return; } bool saved = Save(); if (saved) {this. Close(); } } protected virtual bool Confirm. Close() {return true; } protected virtual bool Save() {return true; } }

www. itransition. co m Page 44 Продолжение примера public class Main. Form : Base. Form { //… protected override Save() { bool saved = true; if (this. Modified && Show. Save. Question()) { try{Save. Data(); } catch(Exception exception) { Process. Exception(exception); //e. g. show message saved = false; } } return saved; } }

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

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

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

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

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

www. itransition. co m Page 55 Пример кода public class Presenter {. . . public Presenter(IView view, I Model model ) { this. view = view; this. model = model ; S ubscribe. To. View. Events(); L oad. View. From. Model(); } }

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

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

www. itransition. co m Page 58 Patterns vs. Anti. Patterns: Recurrent Problems Solution (Pattern) Anti-Patterns: Recurrent Problems “ Solution” with problems of its own (Anti-Pattern) Refactored Solution

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

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

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

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

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

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

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

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

Copyright © 2006 Itransition. Page 71 Все www. itransition. com