682 MGraphics.ru - На примере денег - Вырождающиеся объекты
Уроки photoshopa


Экстремальное программирование - На примере денег

Вырождающиеся объекты

Условия перепечатки материалов

Рейтинг статьи: 0.000.000.000.000.00
Проголосовало 0 человек.
Оцените статью:

Обычный цикл разработки на основе тестирования состоит из следующих этапов:

1. Напишите тест. Представьте, как будет реализована в коде воображаемая вами операция. Продумывая ее интерфейс, опишите все элементы, кото­рые, как вам кажется, понадобятся.

2. Заставьте тест работать. Первоочередная задача — получить зеленую по­лоску. Если очевидно простое и элегантное решение, создайте его. Если же на реализацию такого решения потребуется время, отложите его. Просто отметьте, что к нему придется вернуться, когда будет решена основная за­дача — быстро получить зеленый индикатор. Такой подход довольно не­приятен для опытных разработчиков (в эстетическом плане), ведь они сле­дуют только правилам хорошей разработки. Но зеленая полоска прощает все грехи, правда, всего лишь на мгновение.

3. Улучшите решение. Теперь, когда система уже работает, избавьтесь от про­шлых прегрешений и вернитесь на путь истинной разработки. Удалите дублирование, которое вы внесли, и быстро сделайте так, чтобы полоска снова стала зеленой.

Наша цель — чистый код, который работает (отдельное спасибо Рону Джеф-фризу (Ron Jeffries) за этот слоган). Иногда такой код не по силам даже самым лучшим программистам, и почти всегда он не достижим для большинства про­граммистов (вроде меня). Разделяй и властвуй, приятель, — в этом весь смысл! Сначала мы напишем код, «который работает», после чего создадим «чистый код». Такой подход противоположен модели разработки на основе архитектуры, в ко­тором вы сначала пишете «чистый код», а потом мучаетесь, пытаясь интегриро­вать в проект код, «который работает».

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

$5 * 2 = $10

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

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

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

В нашем списке один тест, но мы замечаем нечто странное: при выполнении операции с объектом Dollar изменяется сам объект. Хотелось бы написать так:

public void testMultiplicationO {

Dollar five= new Dollar(5):

five.times(2);

assertEqualsdO, five.amount):

five.timesO):

assertEquals(15. five.amount); }

Я не могу представить простого способа, который заставит этот тест выполняться. После первого вызова метода times() пять уже больше не пять — на самом деле это уже десять. Если же метод times() будет возвращать новый объект, тогда мы сможем умножать наши исходные пять баксов хоть целый день, и они не из­менятся. Реализуя эту идею, нам потребуется изменить интерфейс объекта Dollar, поэтому придется изменить и тест. Это нормально, ведь вполне возможно, что наши догадки о правильном интерфейсе не более правдоподобны, чем догадки о правильной реализации.

public void testMultiplicationO {

Dollar five= new Dollar(5):

Dollar product= five.times(2);

assertEquals(10. product.amount):

product» five.timesO):

assertEquals(15. product.amount): }

Новый тест не будет компилироваться, пока мы не изменим объявление метода Dollar.times():

Dollar

Dollar timesdnt multiplier) { amount *= multiplier: return null: }

Теперь тест компилируется, но не срабатывает. И это тоже прогресс! Чтобы заставить его работать, придется возвращать новый объект Dollar с правильным значением:

Dollar

Dollar times(int multiplier) {

return new DollarCamount * multiplier): }

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

$5*2 = $10

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

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

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

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

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

• подделать реализацию, иначе говоря, создать заглушку (Fake It) — возвра­щать константу и постепенно заменять константы переменными до тех пор, пока не получим настоящий код. Кстати такой же способ использует и стандартный winamp, хоть и функция довольно громоздкая все равно винамп легко с ней справляется. Для примера можете скачать плеер бесплатно на сайте download.ru, инсталировать и посмотреть пример: "как надо делать".

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

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

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

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

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

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

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

Разместил: MaxxWhite
Опубликовано: 19.05.2008
Статья "Экстремальное программирование - На примере денег - Вырождающиеся объекты" прочтена 4966 раз.





Последние новости