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

Bank
Money reduce(Expression source, String to) {
Sum sum = (Sum) source;
return sum.reduce(to);
}
Sum
public Money reduce(String to) {
int amount = augend.amount + addend.amount;
return new Money(amount, to);
}
На секунд очку заглянем в буд ущее. Привед ение (reduce) суммы к
некоторой валюте не может быть выполнено, если объект Sum не знает
об обменном курсе. Од нако обменный курс хранится в классе Bank,
значит, скорее всего, в буд ущем нам потребуется перед авать в метод
Sum.reduce() еще од ин параметр типа Bank. Од нако сейчас наш код не
требует этого. Поэтому мы не д обавляем никаких лишних параметров,
чтобы лишний раз в них не путаться. (Что касается меня, то искушение

---

было столь велико, что я все-таки д обавил этот параметр, когд а в
первый раз писал д анный код , – мне очень, очень стыд но.)
$5 + 1 °CHF = $10, если курс обмена 2:1
$5 + $5 = $10
Операция $5 + $5 возвращает объект Money
Bank.reduce(Money)
Так, а что же происход ит в случае, если аргументом метод а
Bank.reduce() является объект Money?
Давайте напишем тест, слава богу, перед нами зеленая поло са и мы
не вид им каких-либо д ругих очевид ных спо собов мод ификации код а:
public void testReduceMoney() {
Bank bank = new Bank();
Money result = bank.reduce(Money.dollar(1), "USD");
assertEquals(Money.dollar(1), result);
}
Bank
Money reduce(Expression source, String to) {
if (source instanceof Money) return (Money) source;
Sum sum= (Sum) source;
return sum.reduce(to);
}
Какой кошмар! Отвратительно! Тем не менее мы получили зеленую
поло ску и можем приступать к рефакторингу. Прежд е всего, вместо
прямой проверки класса всегд а след ует использовать полиморфизм.
Класс Sum реализует метод reduce(String), и, если этот метод д обавить в
класс Money, мы сможем включить reduce(String) в со став интерфейса
Expression.
Bank
Money reduce(Expression source, String to) {
if (source instanceof Money)
return (Money) source.reduce(to);
Sum sum = (Sum) source;
return sum.reduce(to);

---

}