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

Sum
Sum(Money augend, Money addend) {
}
Кроме того, класс Sum д олжен под д ерживать интерфейс Expression:
Sum
class Sum implements Expression
Наша система компилируется, од нако тесты терпят неуд ачу – это из-
за того, что конструктор класса Sum не присваивает значений полям (мы
могли бы созд ать «под д ельную» реализацию, инициализировав поля
константами, од нако я обещал д вигаться быстрее):
Sum
Sum(Money augend, Money addend) {
this.augend = augend;
this.addend = addend;
}
Теперь в метод Bank.reduce() перед ается объект класса Sum. Если
суммируются д ве од инаковые валюты и целевая валюта совпад ает с
валютой обоих слагаемых, значит, результатом буд ет объект класса
Money, чье значение буд ет равно сумме значений д вух слагаемых:
public void testReduceSum() {
Expression sum = new Sum(Money.dollar(3), Money.dollar(4));
Bank bank = new Bank();
Money result = bank.reduce(sum, "USD");
assertEquals(Money.dollar(7), result);
}
Я тщательно выбираю значения параметров так, чтобы нарушить
работу существующего теста. Когд а мы привод им (метод reduce())
объект класса Sum к некоторой валюте, в результате (с учетом

---

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