Теперь два конструктора выглядят абсолютно одинаково, и мы можем переместить реализацию в базовый класс:
Money
Money(int amount, String currency) {
this.amount = amount;
this.currency = currency;
}
Franc
Franc(int amount, String currency) {
super(amount, currency);
}
Dollar
Dollar(int amount, String currency) {
super(amount, currency);
}
$5 + 1 °CHF = $10, если курс обмена 2:1
$5 * 2 = $10
Сделать переменную amount закрытым (private) членом
Побочные эффекты в классе Dollar?
Округление денежных величин?
equals()
hashCode()
Равенство значению null
Равенство объектов
5 CHF * 2 = 1 °CHF
Дублирование Dollar/Franc
Общие операции equals()
Общие операции times()
Сравнение франков (Franc) и долларов (Dollar)
Валюта?
Нужен ли тест testFrancMultiplication()?
Мы уже почти готовы переместить реализацию times() в базовый класс, но прежде вспомним, что в данной главе мы
• на некоторое время заблудились в крупномасштабных идеях дизайна и, чтобы разобраться в проблеме, решили начать с решения небольшой задачи, на которую мы уже обратили внимание ранее;
• сделали одинаковыми два конструктора, переместив отличающийся код в вызывающий (фабричный) метод;
• на короткое время отвлеклись от рефакторинга, чтобы добавить в метод times() вызов фабричного метода;
• выполнили аналогичный рефакторинг в отношении класса Dollar за один большой шаг;
• получили два абсолютно идентичных конструктора и переместили код в базовый класс.
10. Избавление от двух разных версий times()
$5 + 1 °CHF = $10, если курс обмена 2:1
$5 * 2 = $10
Сделать переменную amount закрытым (private) членом
Побочные эффекты в классе Dollar?
Округление денежных величин?
equals()
hashCode()
Равенство значению null
Равенство объектов
5 CHF * 2 = 1 °CHF
Дублирование Dollar/Franc
Общие операции equals()
Общие операции times()
Сравнение франков (Franc) и долларов (Dollar)
Валюта?
Нужен ли тест testFrancMultiplication()?
В конце данной главы мы должны получить единый класс Money, соответствующий понятию «деньги». Две реализации метода times() близки друг к другу, однако они не идентичны:
Franc
Money times(int multiplier) {
return Money.franc(amount * multiplier);
}
Dollar
Money times(int multiplier) {
return Money.dollar(amount * multiplier);
}
Увы, я не вижу простого способа добиться идентичности этих методов, однако в некоторых ситуациях, для того чтобы продвинуться дальше, требуется вернуться немного назад, – это напоминает кубик Рубика. Что будет, если мы заменим вызовы фабричных методов операторами new? (Я отлично понимаю, что совсем недавно мы выполнили обратную процедуру – заменили new вызовами фабричных методов. Но что я могу поделать – сейчас мы решаем несколько иную задачу. Понимаю, что это может показаться обескураживающим, однако потерпите немного.)
Franc
Money times(int multiplier) {
return new Franc(amount * multiplier, "CHF");
}
Dollar
Money times(int multiplier) {
return new Dollar(amount * multiplier, "USD");
}
Мы абсолютно уверены, что в экземплярах класса Franc значение поля currency всегда будет равно «CHF», поэтому можем написать:
Franc
Money times(int multiplier) {
return new Franc(amount * multiplier, currency);
}
Сработало! Теперь тот же трюк можно проделать и в отношении класса Dollar:
Dollar
Money times(int multiplier) {
return new Dollar(amount * multiplier,currency);
}
Мы почти закончили. Имеет ли значение, что мы используем в данном случае – Franc или Money? Об этом можно рассуждать в течение некоторого времени исходя из имеющихся знаний о внутреннем устройстве нашей системы, однако у нас есть чистый код и тесты, которые дают нам уверенность в том, что код работает так, как надо. Вместо того чтобы тратить несколько минут на рассуждения, мы можем спросить об этом компьютер. Для этого достаточно внести интересующие нас изменения в код и запустить тесты. Обучая методике TDD, я наблюдаю подобную ситуацию постоянно – опытные умные программисты тратят от 5 до 10 минут на обсуждение вопроса, на который компьютер может дать ответ в течение 15 секунд. Если у вас нет тестов, вам остается только размышлять и предполагать. Если же у вас есть тесты, вместо того, чтобы напрасно тратить время, вы можете провести быстрый эксперимент. Как правило, если у вас есть тесты, быстрее спросить компьютер.
Чтобы провести интересующий нас эксперимент, модифицируем код так, чтобы метод Franc.times() возвращал значение типа Money:
Franc
Money times(int multiplier) {
return new Money (amount * multiplier, currency);
}
В ответ компилятор сообщил, что Money должен быть конкретным (не абстрактным) классом:
Money
class Money
Money times(int amount) {
return null;
}
Получаем красную полоску и сообщение об ошибке: «expected:<Money.Franc@31aebf> but was:<Money.Money@478a43>». Не очень-то информативно. Не так информативно, как нам хотелось бы. Чтобы получить более осмысленное сообщение об ошибке, добавим метод toString():
Money
public String toString() {
return amount + " " + currency;
}
О, ужас! Код без тестов?! Допустимо ли такое? Конечно же, прежде чем писать код метода toString, мы должны были написать соответствующий тест, однако
• мы увидим результаты работы этого метода на экране;
• метод toString() используется только для отладки, поэтому риск, связанный с потенциальными ошибками, невелик;
• перед нами красная полоса, а
