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

 

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

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

Бек К. Экстремальное программирование: разработка через тестирование — СПб.: Питер, 2003. — 224 c.
ISBN 5-8046-0051-6
Скачать (прямая ссылка): bek-k..pdf
Предыдущая << 1 .. 59 60 61 62 63 64 < 65 > 66 67 68 69 70 71 .. 81 >> Следующая


testSumPrinting() {

Sum sum= new Sum(Money.dollar(5), Money.franc(7)); assertEquals("5 USD + 7 CHF", sum.toStringO);

}

String toStringO {

return augend + " + " + addend;

Однако, если мы хотим отобразить объект Expression в виде древовидной структуры, код может выглядеть следующим образом:

testSumPrinting() {

Sum sum= new Sum(Money.dollar(5). Money.franc(7)); ¦ assertEquals("+\n\t5 USD\n\t7 CHF". sum.toStringO):

}

В этом случае нам придется воспользоваться параметром-накопителем, это может выглядеть примерно так:

String toStringO {

IndentingStream writer= new IndentingStreamO;

toString(writer);

return writer.contentsO:

}

void toStringdndentingWriter writer) { writer. printlnC'+"): writer.indentO; augend.toString(writer): writer.printlnO: addend.toString(writer); writer.exdentO:

}

Singleton (Одиночка)

Каким образом можно реализовать глобальную переменную в языке, в котором не поддерживаются глобальные переменные? Не следует этим заниматься. Ваша программа скажет вам большое спасибо, если вместо этого вы еще раз хорошенько обдумаете дизайн и откажетесь от мысли использовать глобальные переменные.

Рефакторинг

Рассматриваемые здесь паттерны помогут вам изменить дизайн системы маленькими шажками.

В рамках TDD рефакторинг1 используется интересным образом. Обычно рефакторинг не может изменить семантику программы ни при каких условиях. В рамках TDD условия семантики формулируются при помощи тестов, которые уже срабатывают. Таким образом, в рамках TDD мы можем, например, заменить константы переменными и с чистой совестью назвать эту процедуру рефакторин-гом, потому что набор срабатывающих тестов при этом не изменился. Однако набор срабатывающих тестов может состоять всего из одного теста. Возможно, семантика программы должна описываться большим количеством тестов. Возможно также, что некоторые из этих потенциальных тестов в результате выполнения рефакторинга перестали бы срабатывать, если бы они существовали. Однако их нет, поэтому мы о них не беспокоимся.

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

Reconcile Differences (Согласование различий)

Каким образом вы можете унифицировать два схожих фрагмента кода? Постепенно делайте их все более похожими друг на друга. Унифицируйте их только в случае, если они абсолютно идентичны.

Fowler, Martin. 1999. Re factoring: Improving the Design of Existing Code. Boston: Addison-Wesley. Русское издание: Файлер. M. Рефакторинг: улучшение существующего кода. СПб.: Символ-Плюс, 2003.

Подчас выполнение рефакторинга — это весьма нервная работа. Простые рефакторинга очевидны. Если я извлекаю метод и делаю это механически корректно, вероятность того, что поведение системы изменится, чрезвычайно мала. Однако некоторые из рефакторингов заставляют вас внимательно анализировать последовательность выполнения операций и порядок модификации данных. Построив длинную цепочку умозаключений, вы приходите к выводу, что запланированное вами изменение кода, скорее всего, не приведет к изменению поведения системы. Однако любой подобный рефакторинг уменьшает количество волос на вашей голове.

Сложные рефакторинги — это именно то, чего мы пытаемся избежать, когда придерживаемся стратегии маленьких шажков и конкретной обратной связи. Полностью избежать сложных рефакторингов невозможно, однако можно уменьшить сферу их влияния на остальной код.

Подобные рефакторинги возникают на разных уровнях:

• Два цикла выглядят похоже. Если вы сделаете их идентичными, вы можете объединить их в единый цикл.

• Две ветви условного оператора выглядят похоже. Сделав их идентичными,

вы можете избавиться от условного оператора.

• Два метода выглядят похоже. Сделав их идентичными, вы можете избавиться от одного из них.

• Два класса выглядят похоже. Сделав их идентичными, вы можете избавиться от одного из них.

Иногда задачу согласования различий удобнее решать в обратном порядке. Иными словами, вы представляете себе самый тривиальный последний этап этой процедуры, а затем двигаетесь в обратном направлении. Например, если вы хотите избавиться от нескольких подклассов, наиболее тривиальный последний шаг можно будет выполнить в случае, если подкласс ничего не содержит. В этом случае везде, где используется подкласс, можно будет использовать суперкласс, при этом поведение системы не изменится. Что надо сделать, чтобы очистить подкласс от методов и данных? Для начала метод можно сделать полностью идентичным одному из методов суперкласса. Постепенно переместив все методы и все данные в суперкласс, вы сможете заменить ссылки на подкласс ссылками на суперкласс. После этого подкласс можно уничтожить.
Предыдущая << 1 .. 59 60 61 62 63 64 < 65 > 66 67 68 69 70 71 .. 81 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100