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

7 В переводе на русский язык sum – это сумма. – Примеч. пер .

$5 + 1 °CHF = $10, если курс обмена 2:1

$5 + $5 = $10

Мы не можем вычеркнуть пункт $5 + $5, пока не удалим из кода все повторяющиеся фрагменты. Внимательно рассмотрим код. В нем нет повторяющегося кода, но есть повторяющиеся данные – $10 в «поддельной» реализации:

Bank

Money reduce(Expression source, String to) {

return Money.dollar(10);

}

Это выражение по своей сути дублирует выражение $5 + $5 в коде теста:

public void testSimpleAddition() {

Money five = Money.dollar(5);

Expression sum = five.plus(five);

Bank bank = new Bank();

Money reduced = bank.reduce(sum, "USD");

assertEquals(Money.dollar(10), reduced);

}

Раньше, если у нас имелась «поддельная» реализация, для нас было очевидным, как можно вернуться назад и сформировать реальную реализацию. Для этого достаточно было заменить константы переменными. Однако в данном случае пока не понимаю, как вернуться назад. Поэтому, несмотря на некоторый риск, я решаю двигаться вперед:

$5 + 1 °CHF = $10, если курс обмена 2:1

$5 + $5 = $10

Операция $5 + $5 возвращает объект Money

Прежде всего, метод Money.plus() должен возвращать не просто объект Money, а реальное выражение (Expression), то есть сумму (Sum). (Возможно, в будущем мы оптимизируем специальный случай сложения двух одинаковых валют, однако это произойдет позже.)

Итак, в результате сложения двух объектов Money должен получиться объект класса Sum:

public void testPlusReturnsSum() {

Money five = Money.dollar(5);

Expression result = five.plus(five);

Sum sum = (Sum) result;

assertEquals(five, sum.augend);

assertEquals(five, sum.addend);

}

(Вы когда-нибудь слышали, что в английском языке первое слагаемое обозначается термином augend , а второе слагаемое – термином addend ? Об этом не слышал даже автор до тех пор, пока не приступил к написанию данной книги.)

Только что написанный тест, скорее всего, проживет недолго. Дело в том, что он сильно связан с конкретной реализацией разрабатываемой нами операции и мало связан с видимым внешним поведением этой операции. Однако, заставив его работать, мы окажемся на шаг ближе к поставленной цели. Чтобы скомпилировать тест, нам потребуется класс Sum с двумя полями: augend и addend:

Sum

class Sum {

Money augend;

Money addend;

}

В результате получаем исключение преобразования классов (ClassCastException) – метод Money.plus() возвращает объект Money, но не объект Sum:

Money

Expression plus(Money addend) {

return new Sum(this, addend);

}

Класс Sum должен иметь конструктор:

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 и благодаря этому избавимся от лишнего уровня ссылок:

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. Однако сейчас наш код не требует этого. Поэтому мы не добавляем никаких лишних параметров, чтобы лишний раз в них не путаться. (Что касается меня, то искушение было столь велико, что я все-таки добавил этот параметр, когда в первый раз писал данный код, – мне очень, очень стыдно.)