Шаблоны ООП. Рефакторинг Разработка бизнес приложений Лекция 7
Шаблоны ООП. Рефакторинг
Разработка бизнес приложений Лекция 7
Зачем нужны шаблоны
• Основная сложность разработки бизнес ПО - подобрать готовые решения и шаблоны, заставить все работать вместе и следить за сложностью (стоимостью) поддержки.
• Все уже придумано до нас
Что такое шаблон ООП
• Шаблон это просто идея взаимодействия группы объектов (сущностей, классов). Реализация может быть очень разной
• Шаблоны – это общий язык общения разработчиков
ШАБЛОНЫ ООП ПРОЕКТИРОВАНИЯ
ПОРОЖДАЮЩИЕ ШАБЛОНЫ
Abstract Factory. Фабрика
• Цель – скрыть тип создаваемого объекта• Так же известен как Factory / FactoryMethod• Используется везде
ProductFactoryA
Product<<Interface>>
ProductA
ProductB
creates
return new ProductA();
ProductFactory
createProduct()
<<Interface>>
ProductFactoryBcreates
return new ProductB();
Singleton. Синглетон.
• Нужен что бы инкапсулировать жизненный цикл объекта
• Чаще всего используется (или приводит к) для эмуляции процедурного программирования
• Т.е. в 99% страшное зло
Singleton
Singleton instance
getInstance()
return instance;
НЕ ИСПОЛЬЗОВАТЬ
Другие порождающие шаблоны
• Prototype– Для создания дорогих объектов
• Builder– Когда конструктор становится слишком
сложным (напр. много параметров) и не имеющим отношения к классу
– Для создания многих похожих объектов подряд (или клонирования)
СТРУКТУРНЫЕ ШАБЛОНЫ
Adapter
• Предоставляет единый (адаптированный) интерфейс для нескольких схожих подсистем
• Часто используется там, где есть различные протоколы интеграции со схожими системами
Consumer
performOperation()
Adapter
operation()
<<Interface>>
AdapterA
AdapteeA
AdapterB
AdapteeB
public void performOperation(){ ... adapter.operation();...}
Proxy
• Реализует тот же интерфейс что и оригинальный объект для прозрачного добавления какого-нибудь функционала
• Ленивая загрузка, удаленный объект, тесты и т.п.
Service
operation()
<<Interface>>
ServiceImpl
operation()
Client
ServiceProxy
operation()
+target
Facade
• Предоставляет четкий интерфейс множества подсистем, часто ограничивая сложность подсистем
• Классическое использование – интерфейс к доменной модели
SubsystemA
SubsystemB
SubsystemC
ExternalConsumer
Facade
operation1()operation2()operation3()operation4()operation5()
Composite
• Дерево вложенных друг в друга однотипных объектов• Писать приходится не часто, но очень часто используется
в стандартных фреймворках (особенно UI). К примеру, XML парсер.
Node
operation()
Composite
add(Component component)remove(Component component)operation()
Component
operation()
<<Interface>>
0..n0..n
вызов метода operation() для каждого дочернего компонента
ПОВЕДЕНЧЕСКИЕ ШАБЛОНЫ
Template method
• Мощнейший комплимент наследованию• Используется повсеместно, для
ограничения нарушения инкапсуляции наследованием
AbstractClass
templateMethod()subOperation1()subOperation2()
ConcreteClass
subOperation1()subOperation2()
templateMethod(){ ... subOperation1(); ... subOperation2(); ...}
Command
• Абстракция любой операции. Если объединить с composite, позволяет строить системы абстрактного выполнения команд группами.
• Уменьшение кол-ва удаленных вызовов, UNDO, транзакции, TCP/IP пакеты
Command
execute()
<<Interface>>
ConcreteCommandUsercreates
Executor
execute(command : Command)executes
+executor
Strategy
• В чем отличие от команды?• Абстракция конкретного алгоритма, с параметрами
State
• Моделирует объект у которого много разных состояний
• Упрощает выражение схемы взаимодействия состояний, ее изменение и расширение
Chain of resp. (FilterChain)
• Модель цепочки обработчиков, позволяет легко добавлять / удалять обработчики
• Обработка HTTP запросов
Другие
• Observer (Publisher / Subscriber)– События – один публикует события, другие ждут,
наблюдают и обрабатывают. В C# реализовано на уровне языка
• Iterator– Шаблон организации итератора по коллекции /
объекту. С C# и многих других языках реализовано по умолчанию (IEnumerable)
• Visitor – Позволяет «добавить» метод к целой иерархии (или
просто набору) классов. Сложно, но бывает нужно.
РЕФАКТОРИНГ
Рефакторинг это
• Преобразование существующего кода без изменения функциональности с целью:– Сделать его лучше и проще в поддержке– Сделать возможным добавление каких-то
новых функций– Иногда решить другие проблемы (напр.
производительности)
Запахи кода
• Дублирование кода (Simian)• Длинные методы (Unix!)• Большой класс• Много параметров• Цикломатическая сложность• Switch• Группы данных• Пустые классы данных
Запахи кода
• Много точек изменений по одному поводу• Очень высокая связность• Лишний или «на будущее» код• Глубокие цепочки вызовов в клиентах• Отказ от наследства• Комментарии
«Научные» принципы
• Single Responsibility• Open for extension, closed for modification• Liskov substitution (объекты всегда
заменимы объектами-наследниками)• Interface segregation (больше специфичных
интерфейсов)• Depend upon abstractions
«Научные» принципы
• Single point of change (единая точка изменений)
• Separation of concerns (SoC) (разделение понятий)
• Command-query separation (СQS) (разделение запросов и команд)
• Единый уровень абстракции
Agile принципы
• YAGNI– You ain’t gonna need it
• KISS– Keep it stupid simple
• DRY– Don’t repeat yourself
НЕКОТОРЫЕ РЕФАКТОРИНГИ
Инкапсуляция поля
Банальные
• Подвинуть метод• Подвинуть поле• Опустить поле / метод вниз / вверх по
иерархии• Замена магических чисел константами• Кодов ошибки эксепшенами и прочии и
касающиеся стиля
Самый важный
И дальше – объект параметр
Потом инкапсуляция всего
• А также полей, методов и всего остального
Метод -> объект
Switch -> полиморфизм
Тип объекта -> наследование
Тип объекта -> state / strategy
Выделить класс (и наоборот)
Выделить наследника (и наоборот)
Выделить базовый класс (и обратно)
Выделить template метод
Выделить интерфейс
Наследование -> композиция
Null объект
UI –> Model / UI
Рефакторинг – это круто
• При наличии тестов / спецификации• При наличии конкретной цели / юскейза• 99% рефакторингов – обратимы, нечего
терять• Рефакторинг поддерживает принципы
YAGNI / KISS • Полный список рефакторингов -> книга / сайт
(www.refactoring.com), но он бесконечный
Ресурсы
• Приемы объектно-ориентированного проектирования. Паттерны проектирования
• Рефакторинг. Улучшение существующего кода
• Чистый код. Создание, анализ и рефакторинг
• Google “<Pattern name> pattern” + картинки)• Google “<аббревиатура>”
Темы для докладов
• AOP• Kanban / Lean (Карпов)• SCRUM: Team / ScrumMaster – подробнее
про процесс (DS, Retro, SprintPlan, Demo…)• Portfolio management, BMG (Alex Ostervald),
Scrum of Scrum• NoSql БД• Реализация ООП в Javascript (прототипы)
Объявлениея
• В следующий четверг лекции не будет– www.msteched.ru
• Давайте решать что делать со временем лекций
• И с лабами, времени остается все меньше
Лабы
• Обработка открытых данных– http://minenergo.gov.ru/activity/statistic/,http://www.fms.gov.ru/about/ofstat/,
http://www.federalspace.ru/main.php?id=10, http://ivan.begtin.name/2011/10/02/gosuslugijson/
• Индивидуальное задание (для тех, у кого уже есть что показать)
• Нужно:– Или наличие БД– Или наличие веб интерфейса– Отчет по лабам
• Стажировка (Тестер / Разработчик)– Нужно знание: C#, MS MVC, MS SQL Server
Использованные материалы
• Никита Филлипов (www.ScrumTrek.ru)– Курс SCPO Msk (31.08.11)
• Бочков Илья (Архитектура корпоративных приложений, МИФИ)
• MIT: electrical-engineering-and-computer-science– http
://ocw.mit.edu/courses/#electrical-engineering-and-computer-science