разработка бизнес приложений (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