Архитектура в Agile: слабая связность

Архитектура в Agile:
компоненты и модули
слабая связность

Бибичев Андрей
март 2011

@bibigine
Андрей Бибичев

• E-mail: bibigone@gmail.com
• Twitter: @bibigine
• Profile: http://www.google.com/profiles/biBIGone
• Slideshare: http://www.slideshare.net/bibigine

Alistair Cockburn:
«starting with a walking skeleton,
then evolving it iteratively»

Mary and Tom Poppendieck:
«divisible system architecture»

Robert Martin (Uncle Bob):
«No doubt that BDUF is harmful.
Size matters! ‘B’ is bad, but ‘L’ is good.
Indeed, LDUF is absolutely essential.»

tr 'A-Z' 'a-z' <fnord.txt
| tr -cs 'a-z' 'n' | sort | uniq
| comm -23 - /usr/share/dict/words

stdin params stdout

Эволюция
1. goto
2. подпрограммы
3. динамические библиотеки
4. классы (ООП)
5. компоненты (COM/CORBA/…)
6. …

Но что-то не легчает №1…

Корнелис Киммель « Снежный ком»

Архитектура в Agile: слабая связность

Сильная связность
≈ каждый с каждым => O(N2)


Код-гидра:
один баг исправишь - несколько появляются

Side-эффекты
Могучий глобальный контекст
+
Мутабельность всего и вся
+
Избыточная область видимости
=
поправил здесь, отвалилось там


GOD-classes

WinForms.Net

Класс Control:
100+ свойств (≈80% public)
400+ методов (≈30% public)
50+ событий (все public)

Разработчик и GOD-класс

А вокруг пустынно и уныло…

История сложности одного файла и
распределение числа check-in по файлам

http://michaelfeathers.typepad.com/michael_feathers
_blog/2011/03/data-rich-development.html


«Рулонные функции»

«Промышленный игрокод»
http://code.google.com/p/lugaru/source/browse/Source/GameTick.cpp?r=cmake#1673

…

10 992 – 1673 + 1 = 9 320 строк

Типичные болезни:
• Сильная связность
• Неуловимые и непознаваемые side-эффекты
• Вездесущий и всеобъемлющий глобальный
контекст (привет любителям singletone-ов!)
• GOD-классы
• Переусложненный и запутанный workflow
• Дублирование логики
• …

Мечтали о: А выходит так:

1. Классы и их
взаимодействие

1.0. Ремарка

Для процедурных языков
• Класс => Структура + функции для неѐ
struct a {
double f(struct a* p, double k) {
int v;
return p->v * p->d / k;
double d;
}
};
• Интерфейс => Структура указателей на функции
(вспомним как работают вызовы к DLL!)
struct i {
f1_t f1; typedef void (*f1_t)(int s);
f2_t f2; typedef double (*f2_t)();
};
• Наследование => Композиция
struct b {
struct a super;
};

1.1. Современное ООП

Длинные «руки» объекта:

если ему чего нужно, то он сам за этим тянется

Укорачиваем руки:
• Inversion-of-Control (IoC)
• Law of Demeter
• Tell, Don’t Ask

Inversion of Control (IoC)
«Consumer»
Компонент

SomeConsumer
Компонент
«Provider»

SomeProvider

«Consumer»
Компонент

SomeConsumer
Компонент
«Provider»

«interface»
SomeProviderImpl
ISomeProvider

«Consumer»
Компонент

«interface»
SomeConsumer
ISomeProvider
Компонент
«Provider»

SomeProviderImpl

I1

I2
MyClass
I3

Что нужно «Торчащий»
для работы API

Как передать имплементации
интерфейсов объекту класса?
• Dependency Injection через конструктор
MyClass {
MyClass(I1 o1, I2 o2) { … } 
• DI через свойство/set-метод
MyClass {
setI1(I1 o1) { … } 
• Service Locator
o1 = MegaContext.resolve<I1>();


Law of Demeter
Any method of an object should only
call methods belonging to:
• itself.
• any parameters that were passed in to
the method.
• any objects it created.
• any composite objects.

Следствия
:
• Global context (включая Service Locator)
MegaContext.Singletone.get<IService>().do()
• Цепочки вызовов
field.getSmth().getSmthElse().Prop.Count

:
• True singletone (e.g. Null Objet)

А работа с фабрикой?
void doSmth(ISomeFactory someFactory) {
ISome some = someFactory.createSome();
some.act();

// someFactory.createSome().act();

• Казалось бы, работа с фабрикой нарушает
принцип Диметры

• Относитесь к фабрике как к переопределению
оператора new. Тогда всѐ становится
нормально: «any objects it created»

Tell, Don’t Ask
Procedural code gets information then
makes decisions. Object-oriented code
tells objects to do things.

— Alec Sharp

void myFunc(Obj obj) {
if (!obj.init()) throw new …;
String id = obj.getId();
log.write(“starting transaction with “ + id);
if (obj.supportTransaction()) {
if (!obj.startTransaction()) throw new …;
Photo photo = obj.GetPhoto();
if (!analyzePhoto(photo)) {
obj.rollback();
obj.kill();
} else {
obj.act();
}
}
}

me: Привет!
obj: Хай!
/* me: Ага, ответила, значит продолжаем разговор */
me: Как тебя зовут?
obj: Саша
me: Саша – красивое имя!
/* me: Блин, мужик или баба?! */
me: А полное имя Александр или Александра?
obj: Александра
/* me: Ура! Баба! */
me: Здорово! Давай куда-нить сходим?
obj: Давай. Только куда?
me: В клуб. Только как я тебя узнаю? Пришли фотку
obj: Держи
/* me: Фу */
me: == disconnected ==

Минусы «чата»:
• Сложный интерфейс
• Тесная связность => С высокой вероятностью
придется согласованно править в двух местах
• Попахивает нарушением инкапсуляции

Инкапсулировать в
другом месте
interface IObj {
void performInTransaction(Callback action);
}

Где риализовывать:
• Либо в классе, с которым мы общаемся
• Либо сделать специализированный wrapper

Декларативный стиль в
императивных языках

• Иди на кухню
• Возьми чашку
• Налей туда заварки
• Мне бы чаю
• Добавь кипятку
• Две ложки сахара
• Поставь на блюдце
• Принеси мне

Дуализм:
интерфейс vs. данные
class MyDoc {
MyDoc(ICurrentDateProvider cdp) {
docDate = cdp.get();
…
Документ }
Дата док-та
…
class MyDoc {
MyDoc(Date date) {
docDate = date;
…
}

Требования к такому
«транспортному» классу:
• Как и интерфейс должен
«жить и мыслиться» вместе с тем
классом, который его использует
• Минималистичный
(только те данные, которые нужны)
• Immutable
• Должны легко конструироваться в любом
состоянии (для тестирования – a la Mock в
случае интерфейсов)
• Сериализуемые (для транспорта)

Это как карпускулярно-
волновой дуализм

Иногда удобнее так, иногда сяк.
Полезно владеть и тем и тем.

Лучше сильно не увлекаться:

• Anemic Model
http://martinfowler.com/bliki/AnemicDomainModel.html

1.2. MVP и Entity-Repository

Классика жанра
• Model-View-Presenter (MVP)
• Entity-Repository

Presentation Appl. Logic Domain

IView
View Presenter Model

SomeControl

Как декомпозировать
сложную форму?

Event Aggregator
aka Message Bus

См. http://martinfowler.com/eaaDev/EventAggregator.html

1.3. Про наследование

Наследование –
тоже вид зависимости,
причем опасный

A

B

1. Общие для нескольких классов
helper-методы и данные к ним

BaseQuery

EntityQuery<T> Query

Base
Class

ClassA ClassB

class Mission {
protected string Id { get; set; }

protected DateTime WhatTimeIsItNow() {
// ...
}
}

class FlyOnTheMoon : Mission {
EngineCommand DetermineNextAction() {
// ...
var time = WhatTimeIsItNow();
// ...
}
}

class SleepInTheBed : Mission {
bool ShouldIWakeUp() {
// ...
var time = WhatTimeIsItNow();
// ...
}
}

Характерные признаки
• Как правило, наследников мало
• Не предполагается написание «своих»
наследников
o базовый класс сурово заточен под нужды своих конкретных
наследников и не предполагает других наследников

• Сам базовый класс нигде в API не фигурирует
o его использование лишено смысла!

• При правках в наследниках очень часто
приходится подкручивать в базовом классе

2. Расширение функциональности
за счет перекрытия виртуальных
protected-методов

Control
OnMouseMove()

МуControl
OnMouseMove()

Умный и
мощный класс
(«на все случаи
жизни»)

Его
исполь-
зование

Характерные признаки
• Виртуальные методы, которые активно
перекрываются в наследниках
• Сам базовый класс инкапсулирует какую-то
общую «идею» (обобщенный алгоритм,
обобщенный компонент), которая лишена
смысла без «правильного» перекрытия
виртуальных методов
• Часто сочетается с (1)
• Массивными override-ами можно
чуть менее чем полностью изменить поведение
базового класса

3. Отражение отношения
«является» (is)
Человек
Дышать()

Мужчина Женщина

Бриться() Рожать()
ПитьПиво() Готовить()
СмотретьФутбол() Убираться()

ClassB

ClassA

BaseClass

The Liskov Substitution
Principle (LSP)
If for each object o1 of type S there is an
object o2 of type T such that for all
programs P defined in terms of T, the
behavior of P is unchanged when o1 is
substituted for o2 then S is a subtype of T.
1988

GIVEN

S o1

P(arg: T)
T o2

WHEN

o1 o2 : P ResultOf[P(o1)]  ResultOf[P(o2)]

THEN

T S

Это проясняет отношение
«является» (is)
Rectangle
Width
Height

Square При присваивании
Width синхронно
меняется Height и
наоборот

Design-by-Contract
• Контракт базового класса не
должен нарушаться наследниками

Rectangle
Width
Height

Square При присваивании
Width синхронно
меняется Height и
наоборот

Как быть?
• Interface over Inheritance
• Composition over Inheritance
• Delegation over Inheritance

1.4. Design by Contract (DbC)

Просто
сигнатуры
методов не
хватает, чтобы
описать API
(как
I1
требуемое,
I2 так и
MyClass предоставляе
I3 мое)

Три кита DbC:
Rectangle
• Пред-условия Width
Пример: w >= 0 Height
Angle
• Пост-условия setWidth(w)
Пример: Width == w
Height == OldValue(Height)
• Инварианты
Пример: Angle == 90

Инструментарий
• Java: cofoja (by google)
@Requires({
"h >= 0",
"h <= 23"
})
@Ensures("getHour() == h")
void setHour(int h);

• C#: CodeContracts (by MS research)
[ContractClassFor(typeof(IMy))]
sealed class ContractForMy : IMy {
void setHour(int h) {
Contract.Requires(h >= 0);
Contract.Requires(h <= 23);
Contract.Ensures(Hour == h);
}

Полезен не статический анализ (он у всех хромает),
а то, что разработчик думает о контракте
и явно декларирует его

1.5. Что еще

Избавление от if-ов
• State
• Strategy
• Null-Object
• Specification

За всж приходиться платить:

Лазанья-код (aka пахлава-код)

Добавление атрибута
сущности:

1. СУБД: поле в таблице
2. Репозиторий (как минимум метаданные Hibernate)
3. [in-memory репозиторий]
4. Сущность
5. Data Transfer Object (DTO)
6. Presenter (N штук)
7. View (N штук)
8. А еще unit-тесты 

Как выкручиваться?
• Функциональное программирование
o Задачи трансформации и обработки данных

• Аспектно-ориентированное
программирование
o Журналирование, проверка прав, валидация …

• Декларативное программирование,
DSL
o Всѐ остальное рутинное 

Пример 1:
IView
View Presenter Model

Model-View-ViewModel
View
View magic Model
Model

Декларативное описание привязки свойств
и событий контролов к свойствам и
командам ViewModel

Пример 2:
• Типовой атрибут:
o Метаданные, описывающие тип значения
o Метаданные, описывающие хранение
o Метаданные, описывающие способ редактирования на UI
o [Метаданные, описывающие права доступа]
o [Метаданные, описывающие кеширование]

• По ним «генерируется»:
o Обновление структуры БД
o Кусок кода сущности
o Реализация в классе репозитория
o Реализация GUI -контрола

Способы генерации:
• Runtime
• Post-compile time (e.g. code-rewrite)
• Additional code generation

Мета-программирование:
• Нельзя сильно увлекаться –
появляется своя слабо познаваемая эклектика
и “зюко-хрючный” синтаксис

• Тяжело обеспечить адекватным
инструментарием для удобной работы с
метаданными

• Должна быть возможность всегда просто
вставить императивный код (Ant vs. Scons)

Пока больше распространены:

• Java: Groovy
• .Net: Boo

3. Взаимодействие
модулей

Проще всего так:
App. Logic App. Logic

Domain Domain

DBMS “A” DBMS “B”

Модуль 1 Модуль 2

Ущербность такого подхода
поняли давно
и используют сервисы

и всѐ это загажено
маркетинговым булшитом 

Приемы проектирования
аналогичны:
• Контракт на API (интерфейс) +
Data Contract

• Подсистемы-адаптеры

• Шина

Серьезное «НО»:

Abstraction Penalty

Примеры борьбы:
• Накладные расходы на транспорт
o SOAP => REST

• Распределенные транзакции
o Double-check commit => Идемпотентные операции

упрощение абстракций!

Идемпотентные операции:
• Повторный вызов ничего не ломает и
ничего не дублирует
o Просто выполняет действие, если до этого оно почему-
то не было завершено
o Если же операция уже была выполнена, то ничего не
делая, возвращает результат еѐ выполнения

• Очень легко реализуется
o Желающим расскажу отдельно 

Зачем всж так сложно?!
• Основная ценность – работающий код!

• Если вы практикуете unit-тестинг, то следующая
ценность – тестопригодный код

• Чтобы не накапливать технический долг и не
становиться заложником кода –
понятный и сопровождаемый код

код, который легко сопровождать и развивать,
писать сложнее и дольше, чем просто
работающий код

макет / мини-тула что-то большое

Если вы согласны
потратить доп.усилия:
1. Research / Алгоритмика / Высокие тех. риски:

Слабо связный, Ясный и
Работающий
тестопригодный чистый
код
код [+ тесты] код

2. Уже есть опыт (по аналогии) / Если вы очень крутой:
Слабо связный, Ясный и
тестопригодный чистый
код [+ тесты] код

Agile как Буддизм
• S.O.L.I.D. принципы
• закон Деметры + Tell, don’t ask
• DbC
• Composition/Delegation over Inheritance
• функциональное программирование
• мета-программирование и DSL
• REST
• индемпотентные сервисы
• …
Это не заповеди
Это направления возможных улучшений

Спасибо за внимание!

Вопросы?

bibigone@gmail.com
@bibigine
http://www.google.com/profiles/biBIGone
http://www.slideshare.net/bibigine

Архитектура в Agile: слабая связность

More Related Content

What's hot (19)

Viewers also liked (17)

Similar to Архитектура в Agile: слабая связность (20)

More from Andrey Bibichev (13)

Архитектура в Agile: слабая связность