Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Бек К. -> "Экстремальное программирование: разработка через тестирование " -> 11

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

Бек К. Экстремальное программирование: разработка через тестирование — СПб.: Питер, 2003. — 224 c.
ISBN 5-8046-0051-6
Скачать (прямая ссылка): bek-k..pdf
Предыдущая << 1 .. 5 6 7 8 9 10 < 11 > 12 13 14 15 16 17 .. 81 >> Следующая


Сделать переменную amount закрытым членом класса Нобочныс эффекты в классе Dollar? Округление денежных величин?

Глава 2 • Вырождающиеся объекты 31

В главе 1, когда мы заставляли тест работать, мы начали с заглушки и постепенно улучшали код, пока он не стал полноценным кодом. Теперь мы кодировали сразу правильную реализацию и молились, пока выполнялись тесты (довольно короткие молитвы, честно говоря — выполнение тестов занимает миллисекунды). Нам повезло, тесты были успешны, и мы вычеркиваем еще один пункт.

Мне известны три способа для быстрого получения зеленого индикатора. Вот первые два из них:

• подделать реализацию, иначе говоря, создать заглушку (Fake It) — возвращать константу и постепенно заменять константы переменными до тех пор, пока не получим настоящий код;

• использовать очевидную реализацию (Obvious Implementation) — просто написать сразу настоящую реализацию.

При практическом использовании TDD я периодически переключаюсь между двумя этими способами. Когда все идет гладко и я знаю, что делать, — я просто создаю одну за другой очевидные реализации (запуская тесты каждый раз, чтобы убедиться, что то, что очевидно мне, также очевидно и компьютеру). Как только я натыкаюсь на красный индикатор, я возвращаюсь к методике «поддельная реализация», после чего провожу рефакторинг. Когда уверенность возвращается, я снова использую методику «очевидная реализация».

Есть еще одна, третья методика, «Триангуляция» (Triangulation), которую мы рассмотрим в главе 3. Подведем итоги. Мы выполнили следующее:

• сформулировали дефект проектирования (побочный эффект) в виде теста, который отказал (из-за дефекта);

• создали заглушку, обеспечившую быструю компиляцию кода;

• заставили тест успешно выполняться, написав вроде бы правильный код. Преобразование чувства (например, отвращения, вызываемого побочными

эффектами) в тест (например, двукратное перемножение одного и того же объекта Dollar) — обычная практика в TDD. Чем дольше я этим занимаюсь, тем легче эстетические суждения переводятся в тесты. В результате мои рассуждения о проектировании становятся более интересными. Сначала мы обсуждаем, должна ли система работать так или по-другому. После определения правильного поведения системы можно поговорить о наилучшем способе реализации этого поведения. Мы можем сколь угодно долго рассуждать об истине и совершенстве за пивом, но раз мы занимаемся программированием, у нас есть возможность оставить пустые разговоры и перейти к конкретике.

Равенство для всех

Если у меня есть целое число и я прибавляю к нему 1, то не предполагаю, что изменится исходное число, — в результате я ожидаю получить новое число. Объекты же обычно ведут себя другим образом. К примеру, если у меня есть контракт и я добавлю 1 к его сумме, то это будет означать, что сумма контракта должна измениться (да, несомненно, это пример для обсуждения многих интересных законов бизнеса, которые мы здесь рассматривать не будем).

Мы можем использовать объекты в качестве значений, так же как используем наш объект Dollar. Соответствующий паттерн называется Value Object (объект-значение). Одно из ограничений этого паттерна заключается в том, что значения атрибутов объекта устанавливаются в конструкторе и никогда в дальнейшем не изменяются.

Значительное преимущество использования паттерна Value Object состоит в том, что не нужно беспокоиться о проблеме наложения имен (aliasing). Скажем, у меня есть чек и я устанавливаю его сумму — $5, а затем присваиваю эти же $5 сумме другого чека. Одна из самых неприятных проблем на моей памяти заключалась в том, что изменение величины первого чека может приводить к непреднамеренному изменению величины второго. Это и есть проблема наложения имен (aliasing).

Когда вы используете Value Objects, не нужно беспокоиться о наложении имен (aliasing). Если у меня есть пять долларов ($5), то они всегда гарантированно будут оставаться именно пятью долларами ($5). Если вдруг кому-то понадобится $7, тогда придется создавать новый объект.

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

Сделать переменную amount закрытым членом класса Побочные эффекты в классе Dollar? Округление денежных величин? equalsQ

Одно из следствий использования Value Objects заключается в том, что все операции должны возвращать результаты в виде новых объектов, о чем было расска-

зано в главе 2. Другое следствие заключается в том, что Value Objects должны реа-лизовывать equals(), операцию проверки равенства, потому что одни $5 ничем не отличаются от других.

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

Сделать переменную "amount" закрытым членом

Побочные эффекты в клоссе Dollar?

Округление денежных величин?

equals()

hashCode()

Кроме того, если использовать Dollar в качестве ключа хэш-таблицы, то, реали-зовывая equalsQ, придется реализовать и hashCode(). Добавим этот пункт в список задач и вернемся к нему, когда это будет необходимо.

Вы ведь не собираетесь немедленно приступить к реализации метода equals()? Отлично, я тоже об этом не думаю. Ударив себя линейкой по руке, я стал размышлять над тем, как протестировать равенство. Для начала $5 должны быть равны $5:
Предыдущая << 1 .. 5 6 7 8 9 10 < 11 > 12 13 14 15 16 17 .. 81 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100