Открытый семинар для студентов в компании CUSTIS (6 июня 2013 года). Лектор: Иван Мальцев, ведущий разработчик Java, сертифицированный разработчик Oracle (OCPJP). Аннотация: Шаблон проектирования — воспроизводимая архитектурная конструкция, представляющая собой решение проблемы проектирования в условиях определенного часто возникающего контекста. Из семинара вы узнаете о выборе и особенностях применения шаблонов проектирования, а также о конкретных способах реализации отдельных паттернов (и антипаттернов). Видеозапись семинара: https://vimeo.com/68121505.

1. Шаблоны проектирования:
основы велосипедостроения
Иван Мальцев
Ведущий разработчик Java
6 июня 2013 года

2. Who is who?
 В CUSTIS – ведущий Java-разработчик
 3 года преподаю в МИФИ
курс «Технология программирования»
 Кодинг 10+ лет, на Java – 5+
 Языки: 90% Java (и все, что около);
в юношестве: СС++, PHPJS, Delphi
 Пишу диссер в области ИИ
 @ivan_maltsev
imaltsev87
2/50

3. Планчик
 Предисловие:
что нам стоит велосипед построить?
 Принципы ООП
 Шаблонное мышление
 Применение шаблонов
3/50

4. Привет
Юре Солдаткину
;))
Ограничения
 Рассматриваем разработку прикладного ПО
 Языки общего назначения (C#, Java, C++)
 Много UML
 Кода тоже достаточно
4/50

5. Вместо предисловия
5/50

6. Я его слепила из того, что было…
6/50

7. Facepalm
7/50

8. Есть контакт?
8/50

9. Принципы ООП (S.O.L.I.D.)
9/50

10. Что такое S.O.L.I.D.?
 S – Single Responsibility Principle (SRP)
(принцип единой ответственности)
 O – Open/Closed Principle (OCP)
(принцип открытоcти/закрытости)
 L – Liskov Substitution Principle (LSP)
(принцип замещения Лисков)
 I – Interface Segregation Principle (ISP)
(принцип разделения интерфейса)
 D – Dependency Inversion Principle (DIP)
(принцип инверсии зависимостей)
10/50

11. Зачем?
 Помогают построить архитектуру приложения,
которое с течением времени будет проще
(дешевле) поддерживать и развивать
 Помогают писать повторно используемый код
помогают ≠
гарантируют
11/50

12. Принцип единой ответственности
 Single Responsibility Principle (SRP):
Не должно быть больше одной причины
для изменения класса
Почему?
Иначе получим хрупкий дизайн (пишем одно –
ломаем другое)
12/50

13. Принцип открытости/закрытости
 Open Close Principle (OCP):
Программные сущности (классы, модули,
функции и т. п.) должны быть открыты
для расширения, но закрыты для изменения
Почему?
Чтобы легко реагировать на изменения
бизнес-логики
13/50

14. Принцип замещения Лисков
 Liskov's Substitution Principle (LSP):
Подтипы должны быть заменяемы
базовыми типами (упр.)
Почему?
Потому что клиентский код начинает
считать производный класс разновидностью
базового, и возможно появление кода, явно
использующего этот факт
14/50

15. Принцип разделения интерфейса
 Interface Segregation Principle (ISP):
Клиенты не должны зависеть от методов,
которые они не используют
Почему?
Универсальный интерфейс приводит
к появлению множества «заглушек»
и, соответственно, ко множеству лишнего
кода, который неудобно поддерживать
15/50

16. Принцип инверсии зависимостей
 Dependency Inversion Principle (DIP):
Модули верхних уровней не должны зависеть
от модулей нижних уровней. Оба типа модулей
должны зависеть от абстракций. Абстракции
не должны зависеть от деталей. Детали должны
зависеть от абстракций
Почему?
Иначе возникает паутина зависимостей,
превращающая реализацию очередного
изменения требований в настоящий кошмар
16/50

17. Из серии «КЭП советует»:
 YAGNI (You Ain't Gonna Need It,
«Вам это не понадобится»):
Отказ добавления функциональности,
в которой нет непосредственной надобности
Зачем делать то, что может никогда
не понадобиться?
Почему?
17/50

18. Брюс Тогназзини:
Пролистав книгу о принципах магии
и не взглянув на обложку, сложно не решить,
что это книга о разработке программного
обеспечения.
18/50

19. «Шаблонное мышление»
19/50

20. Шаблоны проектирования
 Design Pattern
 Шаблон (паттерн) представляет собой формализованное
описание часто встречающейся задачи проектирования,
удачное решение данной задачи, а также рекомендации
по применению этого решения в различных ситуациях
 Абстракция объектов, классов и их взаимодействия
 Классический шаблон проектирования обязательно
имеет:
 Название (несколько)
 Проблема: мотивация, контекст, условия применения
 Решение: UML-подобная диаграмма, (псевдо)код
 Последствия: выигрыш и компромиссы
20/50

21. Почему?
 Название прижилось в 70-х годах после
выхода в свет книги по архитектуре
(Кристофер Александер)
 В 1987 г. Кент Бек и Вард Каннигем применили
эти идеи в разработке графических оболочек
на языке SmallTalk
 В 1988 г. Эрих Гамма написал докторскую
о приложении идей шаблонов к разработке ПО
 В 1991 г. Джеймс Коплин опубликовал книгу
Advanced C++ Idioms
21/50

22. Зачем?
 Повышает устойчивость системы
к изменению требований
 Понять чужой код гораздо быстрее
 Меньше времени, которое тратится
на обсуждение и принятие решения
 Одинаковое понимание дизайна
 Понимание работы сторонних
инструментов и библиотек
22/50

23. «Банда четырех» (Gang of Four)
 Эрих Гамма
 Ричард Хелм
 Ральф Джонсон
 Джон Влиссидс
«Приемы объектно-ориентированного
проектирования. Паттерны проектирования»
23/50

24. Классификация GoF-шаблонов
 Порождающие шаблоны (Creational) абстрагируют
процесс создания объектов и позволяют сделать
систему независимой от способа создания,
композиции и представления объектов
 Структурные шаблоны (Structural) определяют
различные сложные структуры, которые изменяют
интерфейс уже существующих объектов или его
реализацию
 Поведенческие шаблоны (Behavioral) определяют
взаимодействие между объектами, увеличивая
таким образом его гибкость
24/50

25. Все GoF шаблоны
23 шт.
25/50

26. Шаблоны тут, шаблоны там
 Шаблоны многопоточного программирования
 MVC (Model-View-Controller)
 Шаблоны корпоративных приложений
(интеграционные)
 Аналитические шаблоны
 IoC (Inversion of Control)
 GRASP-шаблоны
распределения обязанностей
 Антишаблоны
Привет
Сергею Кошелю
;))
26/50

27. Pit Stop
27/50

28. Применение шаблонов
Design
28/50

29. Производящие шаблоны
29/50

30. Игровой мир
Singleton (одиночка)
 Гарантирует, что класс имеет только один
экземпляр в приложении и предоставляет
глобальную точку доступа к этому экземпляру
30/50

31. Варианты реализации Singleton
 Thread-safe (см. Double check locking)
 Lazy vs Non-lazy
 Enumeration – проще всего
Не стоит злоупотреблять частым
применением – может привести
к множеству глобальных зависимостей
31/50

32. Элементы игровой карты
Factory Method (Фабричный метод)
 Определяет интерфейс для создания
объектов
 Делегирует создание объектов своим
наследникам
 Пример: создание элементов
карты игрового мира
32/50

33. Фабричный метод изнутри
 Два вида файлов текстур: зимние и летние
 Как они выглядят, нам не важно, но мы знаем,
что мы получим тот вид, который хотим
 Фабрика загружает текстуру из файла
в память
 Создает элемент карты, содержащий
текстуру
 Возвращает готовый элемент карты
классу-клиенту
33/50

34. Фабричный метод снаружи
34/50

35. Вопрос
Что будет, если объединить несколько
фабричных методов в одном интерфейсе?
Ответ – абстрактная фабрика
Предоставляет интерфейс для создания
семейств взаимосвязанных объектов,
не специфицируя их конкретных классов
35/50

36. Абстрактная фабрика
36/50

37. Builder (Строитель)
 Фабричный метод для сложных объектов
 Создает объект не весь сразу, а по частям
Пример: строитель всей игровой карты
 Делегирует вызовы соответствующим
абстрактным фабрикам
 Составом объекта управляет
класс-клиент
37/50

38. Структурные шаблоны
38/50

39. Adapter (Адаптер)
 Система поддерживает требуемые данные
и поведение, но имеет неподходящий
интерфейс
 Предусматривает создание класса-
оболочки с требуемым интерфейсом
39/50

40. Пример адаптера
 Интеграция с социальной сетью
40/50

41. А если хотим все сразу?
 Задача: обеспечить унифицированный интерфейс
с набором разных компонент другой подсистемы
 Решение: интерфейс, который абстрагирует работу
с несколькими адаптерами
 Пример: интеграция с множеством социальных сетей
41/50

42. Вконташа разочаровала
 Переделали API доступа и стали возвращать
пользователя в другом методе
 На помощь нам приходит шаблон Decorator
42/50

43. Поведенческие шаблоны
43/50

44. Котики-наблюдатели
 Observer (Наблюдатель)
 Также известен как «издатель-подписчик»
(Publisher-Subscriber)
 Задача: сделать в игре счетчики ресурсов,
то есть золото, дерево и т. д.
44/50

45. Реализация наблюдателя
Рабочий
Счетчик
золота
45/50

46. Strategy (Стратегия)
 Необходимо изменять поведение юнитов
во время игры (динамически)
 Похож на фабрику, но не создает объектов,
а реализует их поведение
 Альтернатива множеству условных переходов
(«переключателей»)
46/50

47. А как реализовать управление?
 Нужно, чтобы юниты перемещались
по нажатию мышки
 Обработчик мышки и юниты независимы
 Command (Команда)
Обработчик
Юнит
47/50

48. А как изменять состояние?
 State (состояние)
 Изменяем уровень прокачки юнита
 Необходимо гарантировать
последовательность переходов
48/50

49. Литература
49/50

50. Спасибо!
Вопросы?
Спасибо!
Вопросы?
Иван Мальцев
maltsev@custis.ru
50/50