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

Money
public Money reduce(String to) {
return this;
}
Включаем метод reduce(String) в со став интерфейса Expression:
Expression
Money reduce(String to);
Теперь можно избавиться от этих урод ливых операций привед ения
типа и проверок классов:
Bank
Money reduce(Expression source, String to) {
return source.reduce(to);
}
Я не вполне д оволен ситуацией, когд а в интерфейсе Expression и
классе Bank присутствуют метод ы с од инаковыми именами, но с разным
набором параметров. Я так и не смог найти приемлемого решения этой
проблемы в Java. В языках, гд е под д ерживаются ключевые параметры,
разница 
межд у 
метод ами 
Bank.reduce(Expression, 
String) 
и
Expression.reduce(String) д елается очевид ной благод аря синтаксису
языка. Од нако в языках, в которых различие параметров опред еляется
различием их позиций в списке параметров, разница межд у д вумя
под обными метод ами становится менее очевид ной.
$5 + 1 °CHF = $10, если курс обмена 2:1
$5 + $5 = $10
Операция $5 + $5 возвращает объект Money
Bank.reduce(Money)
Привед ение объекта Money с од новременной конверсией валют
Reduce(Bank,String)
Теперь можно приступить к зад аче реального обмена од ной валюты
на д ругую.

---

В д анной главе мы
• не отметили тест как завершенный, так как не избавились от
д ублирования;
• чтобы прояснить реализацию, решили д вигаться вперед вместо
того, чтобы д вигаться назад ;
• написали тест, чтобы форсировать созд ание объекта, который, как
нам кажется, потребуется в буд ущем (объект класса Sum);
• ускорили процесс реализации (конструктор класса Sum);
• реализовали код с привед ением типов в од ном месте, д обились
успешного выполнения тестов, а затем переместили код туд а, гд е он
д олжен наход иться;
• использовали полиморфизм, чтобы избавиться от явной проверки
типа (класса).

---