Экстремальное программирование. Разработка через тестирование

OvalFigure
(0, 10, 50, 100));
RecordingMedium brush = new RecordingMedium();
d. display(brush);
assertEquals("
oval
0 10 50 100\n", brush.log());
}
Как правило, чтобы увид еть необход имо сть использования этого
шаблона еще д о начала разработки код а, требуется озарение. Именно
озарением можно назвать момент, когд а Уорд Каннингэм решил, что
вектор объектов Money может вести себя так же, как од иночный объект
Money. Сначала можно под умать, что они различаются, од нако по сле вы
понимаете, что они од инаковы.
Вот д ва примера использования «Самозванец» (Imposter) в процессе
рефакторинга:

---

• «Нуль-объект» (Null Object) – вы можете рассматривать отсутствие
д анных в точно сти так же, как и присутствие д анных;
• «Компоновщик» (Composite) – вы можете рассматривать
коллекцию объектов как од иночный объект.
Решение об использовании «Самозванец» (Imposter) в процессе
рефакторинга принимается д ля устранения д ублирования, впрочем,
целью любого рефакторинга является устранение д ублирования.
Компоновщик (Composite)
Как лучше всего реализовать объект, чье повед ение является
композицией функций некоторого набора д ругих объектов? Примените
шаблон «Самозванец» (Imposter) – заставьте этот объект вести себя
под обно тому, как вед ут себя отд ельные объекты, вход ящие в набор.
Мой любимый пример о снован на д вух объектах: Account (счет) и
Transaction (транзакция). Этот пример помимо прочего д емонстрирует
некоторую противоречиво сть шаблона «Компоновщик» (Composite), но
об этом позже. В объекте Transaction хранится изменение величины
счета (безусловно, транзакция – это более сложный и интересный
объект, од нако на д анный момент мы ограничимся лишь мизерной д олей
его возможно стей):
Transaction
Transaction(Money value) {
this.value = value;
}
Объект Accout вычисляет баланс счета путем суммирования
значений отно сящихся к нему объектов Transaction:
Account
Transaction transactions[];
Money balance() {
Money sum = Money.zero();
for (int i = 0; i < transactions.length; i++)
sum = sum.plus(transactions[i].value);
return sum;
}

---

Все выгляд ит д о статочно про сто:
• в объектах Transaction хранятся значения;
• в объекте Account хранится баланс.
Теперь самое интересное. У клиента есть несколько счетов, и он
хочет узнать общий баланс по всем этим счетам. Первая мысль, которая
приход ит в голову: созд ать новый класс OverallAccount, который
суммирует балансы д ля некоторого набора объектов Account.
Дублирование! Дублирование!
А что, если классы Account и Transaction буд ут под д ерживать од ин
и тот же интерфейс? Давайте назовем его Holding (сбережения), потому
что сейчас мне не уд ается прид умать что-либо лучшее:
Holding
interface Holding
Money balance();
Чтобы реализовать метод balance() в классе Transaction, д о статочно
вернуть хранящееся в этом классе значение: