'

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

Понравилась презентация – покажи это...





Слайд 0

Шаблоны проектирования © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 1

План Что такое шаблон проектирования? История появления Преимущества и критика Классификация шаблонов проектирования Примеры некоторых шаблонов Моделирование системы управления движением транспорта на перекрёстке с применением шаблонов проектирования Выводы © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 2

Что такое шаблон проектирования? В процессе написания программ (как и в любой другой области) часто возникают похожие задачи Мы люди умные, и не хотим каждый раз “изобретать велосипед” Мы можем выработать готовые решения для этих похожих задач и использовать их при необходимости Такие решения называются шаблонами проектирования © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 3

Что такое шаблон проектирования? Шаблон проектирования (англ. design pattern) – многократно используемое решение распространённых задач при разработке программного обеспечения По своей сути шаблоны – абстрактные решения для абстрактных ситуаций © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 4

История появления Шаблоны проектирования впервые появились в строительной архитектуре. Человечество на сегодняшний день: 5000 лет опыта в строительстве Менее 40 лет опыта в разработке и проектировании ПО © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 5

История появления Кристофер Александер – архитектор и филосов. Две книги: “A Pattern Labguage: Towns, Buildings, Constructions” (Oxford University Press, 1977) “The Timeless Way of Building” (Oxford University Press, 1979) Идеи нашли применение в других областях, в том числе и в разработке ПО Эрик Гамма, Ричард Хелм, Джон Влиссидес, Ральф Джонсон – “Design patterns” или “Gang of Four” (GoF – банда четырёх), середина 1990-х © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 6

Преимущества Стандартный шаблон можно хорошо проработать В программах, где он используется, будет меньше кода, потенциально содержащего ошибки Упрощается коммуникации между программистами Если два программиста говорят об одной и той же ситуации, но разными словами – они могут друг друга не понять. Когда они говорят о стандартном шаблоне – обоим понятно, о чём идёт речь. Легче разобраться в новой системе – в ней есть знакомые части Всё придумано до нас Существует множество готовых и проверенных временем стандартных шаблонов. Мы можем использовать их в своих программах. © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 7

Критика Зацикливание на шаблонах порождает привычку пользоваться стандартными вещами и отучает нас придумывать нестандартные решения Шаблоны часто применяют слепо, поэтому использование оборачивается только ограничениями: “У нас есть задача - этот шаблон лучше всего её решает - выбираем его“ – правильно “Я знаю клёвый шаблон - давайте подгоним под него задачу” – не правильно © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 8

Классификация шаблонов Основные Порождающие Структурные Поведенческие Разделяющие Архитектурные Анти-паттерны И другие © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 9

Классификация шаблонов Основные Фундаментальные, используются другими шаблонами Delegation, interface, abstract superclass, interface and abstract class, immutable, marker-interface, proxy Порождающие Делают систему независимой от процесса создания объектов Factory method, abstract factory, builder, prototype, singleton, object pool © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 10

Классификация шаблонов Структурные Описывают, как их классов и объектов собираются более крупные структуры Adapter, iterator, bridge, facade, flyweight, dynamic linkage, virtual proxy, decorator, cache management Поведенческие Определяют взаимодействие между компонентами. Увеличивают его гибкость Chain of responsibility, command, little language, mediator, snapshot, observer, state, null object, strategy, template method, visitor © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 11

Классификация шаблонов Разделяющие Описывают, как их классов и объектов собираются более крупные структуры Filter, composite, read only interface Архитектурные Определяют взаимодействие между компонентами. Увеличивают его гибкость Modev-view-controller, layer, client-server… Анти-паттерны Как не следует поступать при разработке программ © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 12

Singleton (одиночка) Гарантирует, что у класса есть только один экземпляр и предоставляет к нему глобальную точку доступа Сам класс запрещает создание дополнительных экземпляров © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 13

Singleton (одиночка) © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam public class Singleton { private static Singleton instanse; private String message = "Hello, I'm Singleton!"; private Singleton() { } public static synchronized Singleton getInstanse() { if (instanse == null) { instanse = new Singleton(); } return instanse; } public void say() { System.out.println(message); } }


Слайд 14

Singleton (одиночка) Цели использования Централизованное управление ресурсом Доступ из любой точки программы Создание объекта требует больших ресурсов памяти или процессора Примеры из жизни Текущий проигрываемый аудиоклип в плеере Текущий пользователь в системе Класс для локализации Spring application context (требует много ресурсов) Hibernate session factory (при создании считывает конфигурационные файлы) © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 15

Builder (Строитель) Делает процесс создания сложного объекта независимым от того, как конструируются сами части и как они взаимодействуют между собой © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam Состоит из нескольких ролей: Builder - определяет, как создаются части Director - определяет, как собирается объект из этих частей Product – то, что получается в результате построения


Слайд 16

Builder (Строитель) class Pizza { private String dough = ""; private String sauce = ""; private String topping = ""; public void setDough(String dough) { this.dough = dough; } public void setSauce(String sauce) { this.sauce = sauce; } public void setTopping(String topping) { this.topping = topping; } } abstract class PizzaBuilder { protected Pizza pizza; public Pizza getPizza() { return pizza; } public void createNewPizzaProduct() { pizza = new Pizza(); } public abstract void buildDough(); public abstract void buildSauce(); public abstract void buildTopping(); } © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 17

Builder (Строитель) class HawaiianPizzaBuilder extends PizzaBuilder { public void buildDough() { pizza.setDough("cross"); } public void buildSauce() { pizza.setSauce("mild"); } public void buildTopping() { pizza.setTopping("ham+pineapple"); } } class SpicyPizzaBuilder extends PizzaBuilder { public void buildDough() { pizza.setDough("pan baked"); } public void buildSauce() { pizza.setSauce("hot"); } public void buildTopping() { pizza.setTopping("pepperoni+salami"); } } © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 18

Builder (Строитель) class Cook { private PizzaBuilder pizzaBuilder; public void setPizzaBuilder(PizzaBuilder pb) { pizzaBuilder = pb; } public Pizza getPizza() { return pizzaBuilder.getPizza(); } public void constructPizza() { pizzaBuilder.createNewPizzaProduct(); pizzaBuilder.buildDough(); pizzaBuilder.buildSauce(); pizzaBuilder.buildTopping(); } } public class BuilderExample { public static void main(String[] args) { Cook cook = new Cook(); PizzaBuilder hawaiianPizzaBuilder = new HawaiianPizzaBuilder(); PizzaBuilder spicyPizzaBuilder = new SpicyPizzaBuilder(); cook.setPizzaBuilder(hawaiianPizzaBuilder); cook.constructPizza(); Pizza hawaiian = cook.getPizza(); cook.setPizzaBuilder(spicyPizzaBuilder); cook.constructPizza(); Pizza spicy = cook.getPizza(); } } © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 19

Builder (Строитель) Пример – выборка товара из каталога по сложным критериям При выборе очередного критерия могут открываться новые контролы Builder: различный для каждого типа товаров: фотоаппараты, телефоны, плееры Director: форма выбора товара Product: объект с критериями © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 20

Abstract Factory (Абстрактная фабрика) Интерфейс для создания группы объектов, принадлежащих одному набору классов и используемых совместно Конкретные классы созданных объектов неизвестны Система не зависит от того, как создаются объекты Логика создания объектов спрятана в фабрике Абстрактная фабрика переопределяется в конкретных классах-фабриках © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 21

Abstract Factory (Абстрактная фабрика) Пример – различные стили пользовательского интерфейса Мы хотим, чтобы в программе можно было поменять тему оформления Описываем интерфейс для фабрики, которая создаёт компоненты пользовательского интерфейса: кнопки, текстовые поля, списки, и т.д. Для каждой темы делаем свою реализацию фабрики В любой момент подменяем одну фабрику на другую и внешний вид пользовательского интерфейса меняется © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 22

Abstract Factory (Абстрактная фабрика) © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 23

Abstract Factory (Абстрактная фабрика) interface GUIFactory { public Button createButton(); } class WinFactory implements GUIFactory { public Button createButton() { return new WinButton(); } } class LinuxFactory implements GUIFactory { public Button createButton() { return new LinuxButton(); } } interface Button { public void paint(); } © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 24

Abstract Factory (Абстрактная фабрика) class WinButton implements Button { public void paint() { System.out.println("I'm a WinButton"); } } class LinuxButton implements Button { public void paint() { System.out.println("I'm an LinuxButton"); } } class Application { public Application(GUIFactory factory) { Button button = factory.createButton(); button.paint(); } } public class Main{ public static void main(String[] args) { new Application(new LinuxFactory()); } } © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 25

Observer (Наблюдатель) Второе название – “издатель-подписчик” Один объект генерирует события, другие объекты эти события получает и на них реагируют Первый объект – наблюдаемый (издатель), остальные – наблюдатели (подписчики) © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 26

Observer (Наблюдатель) © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam import java.util.Observable; import java.util.Observer; public class MyObservable extends Observable { public void doSomething() { setChanged(); notifyObservers(); } } public class MyObserver implements Observer { public void update (Observable obj, Object arg) { System.out.println(“updated”); } } public class MyApp { public static void main(String args[]) { MyObservable a = new MyObservable(); MyObserver b = new MyObserver(); a.addObserver(b); a.doSomething(); }


Слайд 27

Observer (Наблюдатель) Пример – диаграмма в Excell, построенная по таблице При изменении данных в таблице – меняется диаграмма Объект “диаграмма” является подписчиком всех объектов “ячейка” © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 28

Strategy (Стратегия) Общий интерфейс для абстрактного алгоритма Разные реализации конкретных алгоритмов - стратегий Если нужно поменять алгоритм – подменяем одну стратегию другой © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 29

Strategy (Стратегия) class StrategyExample { public static void main(String[] args) { IStragtegy myStrategy; myStrategy = new AddStrategy(); int resultA = myStrategy.count (3,4); myStrategy = new MultStrategy(); int resultB = myStrategy .count(3,4); } } interface Strategy { int count(int a, int b); } class AddStrategy implements IStrategy { public int count(int a, int b) { return a + b; } } class MultStrategy implements IStrategy { public int count(int a, int b) { return a * b; } } © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 30

Strategy (Стратегия) Пример 1 – фильтры в Photoshop, на вход подаётся изображение, к нему применяется стратегия-фильтр Пример 2 – поведение ботов в играх Пример 3 – Forex, каждый участник может реализовать свой алгоритм, который будет вести торги © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 31

Facade (Фасад) Единая обёртка для группы классов Мы пользуемся фасадом и не думаем о классах, которые лежат за ним Уменьшается связанность между частями системы © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 32

Facade (Фасад) Пример – любые библиотеки и модули, у которых описан интерфейс © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 33

Facade (Фасад) public class MessageHeader { private String from; private String to; public String getFrom() { return from; } public void setFrom(String from) { this.from = from; } public String getTo() { return to; } public void setTo(String to) { this.to = to; } } public class MessageBody { private String text; public String getText() { return text; } public void setText(String text) { this.text = text; } } © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 34

Facade (Фасад) public class Message { private MessageBody body; private MessageHeader header; public MessageBody getBody() { return body; } public void setBody(MessageBody body) { this.body = body; } public MessageHeader getHeader() { return header; } public void setHeader(MessageHeader header) { this.header = header; } } © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 35

Facade (Фасад) public class MessageCreatorFacade { private Message message = new Message(); private MessageHeader mh = new MessageHeader(); private MessageBody mb = new MessageBody(); public void setFrom(String from) { mh.setFrom(from); } public void setTo(String to) { mh.setTo(to); } public void setText(String text) { mb.setText(text); } public Message createMessage() { message.setBody(mb); message.setHeader(mh); return message; } } © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 36

Моделируем систему управления движением на перекрёстке Первый этап: GUI-интерфейс вместо светофоров – картинки вместо датчиков – кнопки Представление и логика должны быть разделены Кнопки и картинки должны замениться драйверами реальных устройств Переключение светофоров задаётся таблицей © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 37

Таблица переключений © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 38

Требования к системе Система должна иметь возможность конфигурирования под любой перекрёсток Система должна поддерживать различные режимы работы: обычное переключение ночной режим (датчик фиксирует приближение автомобиля ему включается зелёный свет) К системе должны подключаться любые модели и типы светофоров В любой момент пересечение перекрёстка должно быть безопасным © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 39

Мой вариант © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 40

Выводы Использование паттернов избавляет от необходимости постоянно придумывать новые решения В этом как положительный, так и отрицательный момент Использование паттернов делает код менее подверженным ошибкам Знание паттернов упрощает коммуникации между разработчиками Зная паттерны - мы имеем множество готовых решений наших задач © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


Слайд 41

Спасибо за внимание Презентацию можно будет найти на сайте, когда он откроется ? © Belarus Open Source Laboratory, TechDay Докладчик: Константин Слисенко, JazzTeam


×

HTML:





Ссылка: