Иногда, когда нужно выделить интерфейс, вы используете шаблон «Тестирование обработки ошибок» (Crash Test Dummy) или «Поддельный объект» (Mock Object). В этом случае подбор подходящего имени выполняется сложнее, так как в вашем распоряжении лишь один пример использования интерфейса. В подобных случаях у меня возникает соблазн наплевать на информативность и назвать интерфейс IFile, а реализующий его класс – File. Однако я приучил себя останавливаться на мгновение и размышлять о том, достаточно ли хорошо я понимаю то, над чем работаю? Возможно, интерфейс лучше назвать File, а реализующий его класс – DiskFile, так как соответствующая реализация основана на том, что данные, содержащиеся в файле, хранятся на жестком диске.
Как можно переместить метод в новое место, где он должен находиться? Добавьте его в класс, которому он должен принадлежать, затем обратитесь к нему.
Как
1. Скопируйте метод в буфер обмена.
2. Вставьте метод в целевой класс. Присвойте ему подобающее имя. Скомпилируйте его.
3. Если внутри метода происходит обращение к первоначальному объекту, добавьте параметр, при помощи которого методу будет передаваться этот объект. Если внутри метода происходит обращение к переменным-членам первоначального объекта, передавайте их в виде параметров. Если внутри метода переменным-членам первоначального объекта присваиваются значения, вы должны отказаться от идеи переноса метода в новый объект.
4. Замените тело первоначального метода обращением к новому методу.
Зачем
Это один из моих самых любимых шаблонов рефакторинга, выполняемых в процессе консультирования. Дело в том, что он наиболее эффективно демонстрирует неправильные предположения относительно дизайна кода. Вычисление площади – это обязанность объекта Shape (фигура):
Shape
…
int width = bounds.right() – bounds.left();
int height = bounds.bottom() – bounds.top();
int area = width * height;
…
Каждый раз, когда я вижу, что внутри метода, принадлежащего одному объекту, происходит обращение к нескольким методам другого объекта, я начинаю смотреть на код с подозрением. В данном случае я вижу, что в методе, принадлежащем объекту Shape, происходит обращение к четырем методам объекта bounds (класс Rectangle). Пришло время переместить эту часть метода в класс Rectangle:
Rectangle
public int area() {
int width = this.right() – this.left();
int height = this.bottom() – this.top();
return width * height;
}
Shape
…
int area = bounds.area();
…
Шаблон рефакторинга «Перемещение метода» (Move Method) обладает тремя важными преимуществами:
• Очень легко увидеть необходимость применения этого вида рефакторинга, при этом не требуется глубокое понимание смысла кода. Как только вы увидите два или больше сообщения, адресованные другому объекту, значит, можно смело приступать.
• Механика выполнения рефакторинга быстра и безопасна.
• Результаты зачастую приводят к просветлению. «Но класс Rectangle не выполняет никаких вычислений… О! Теперь я вижу. Так действительно лучше.»
Иногда возникает желание переместить только часть метода. Вы можете вначале выделить метод, переместить весь метод, а затем встроить метод в первоначальный класс. Или вы можете придумать способ сделать все это за один шаг.
Как лучше всего реализовать сложный метод, использующий несколько параметров и локальных переменных? Преобразуйте метод в отдельный объект.
Как
1. Создайте класс с таким же количеством параметров, как и оригинальный метод.
2. Сделайте локальные переменные метода переменными экземпляра нового класса.
3. Определите в новом классе метод с именем run(). Тело этого метода будет таким же, как и тело оригинального метода.
4. В оригинальном методе создайте новый объект и обратитесь к методу run() этого объекта.
Зачем
Объекты-методы полезны в качестве подготовительного этапа перед добавлением в систему абсолютно нового вида внутренней логики. Например, представьте, что для вычисления общего денежного потока используется несколько разных методов, позволяющих учесть в вычислениях несколько разных компонентов общего денежного потока. Вначале можно создать объект-метод, вычисляющий общий денежный поток первым способом. Затем можно описать следующий способ вычислений при помощи тестов меньшего масштаба. После этого добавление в программу нового способа вычислений будет несложным делом.
Объекты-методы также позволяют упростить код, в отношении которого неудобно использовать шаблон «Выделение метода» (Extract Method). В некоторых ситуациях вы вынуждены иметь дело с блоком кода, который работает с обширным набором временных переменных и параметров, и каждый раз, когда вы пытаетесь выделить хотя бы часть этого кода в отдельный метод, вы вынуждены переносить в новый метод пять или шесть временных переменных и параметров. Получившийся выделенный метод выглядит ничем не лучше, чем первоначальный код, так как его сигнатура слишком длинна. В результате создания объекта-метода вы получаете новое пространство имен, в рамках которого можете извлекать методы, без необходимости передачи в них каких-либо параметров.
Как можно добавить в метод новый параметр?
Как
1. Если метод входит в состав интерфейса, сначала добавьте параметр в интерфейс.
2. Воспользуйтесь сообщениями компилятора, чтобы узнать, в каких местах происходит обращение к данному методу. В каждом из этих мест внесите необходимые изменения в вызывающий код.
Зачем
Добавление параметра зачастую связано с расширением функциональности. Чтобы обеспечить успешное выполнение первого теста, вы написали код без параметра, однако далее условия изменились, и для корректного выполнения вычислений необходимо принять во внимание дополнительные данные.
Добавление параметра также может быть вызвано необходимостью миграции от одного представления данных к другому. Вначале вы добавляете параметр, затем удаляете из кода все ссылки на старый параметр, затем удаляете сам старый параметр.
Как переместить параметр из метода или методов в конструктор?
Как
1. Добавьте параметр в конструктор.
2. Добавьте в класс переменную экземпляра с тем же именем, что и параметр.
3. Установите значение переменной в конструкторе.
4. Одну за другой преобразуйте ссылки parameter в ссылки this.parameter.
5. Когда в коде не останется ни одной ссылки на параметр, удалите параметр из метода.
6. После этого удалите ненужный теперь префикс this.
7. Присвойте переменной подходящее имя.
Зачем
Если вы передаете один и тот же параметр нескольким разным методам одного и того же объекта, вы можете упростить API, передав параметр только один раз (устранив дублирование). Напротив, если вы обнаружили, что некоторая переменная экземпляра используется только в одном методе объекта, вы можете выполнить обратный рефакторинг.
27 Fowler, Martin. Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley, 1999. Русское издание: Фаулер. М. Рефакторинг: улучшение существующего кода. СПб.: Символ-Плюс, 2003
32. Развитие навыков TDD
В данной главе я намерен сформулировать несколько вопросов, над которыми полезно подумать, если вы намерены интегрировать TDD в свой процесс разработки. Некоторые из вопросов просты, другие требуют тщательного обдумывания. Ответы на некоторые из этих вопросов вы найдете здесь же, однако иногда, чтобы ответить на некоторый вопрос, вам придется провести собственные исследования.
В этом вопросе на самом деле скрыто два вопроса:
• Какой объем функциональности должен охватывать каждый тест?
• Как много промежуточных стадий должно быть преодолено в процессе каждого сеанса рефакторинга?
Вы можете писать тесты так, что каждый из них будет требовать добавления в функциональный код единственной строки и выполнения небольшого рефакторинга. Вы также можете писать тесты так, что каждый из них будет требовать добавления в функциональный код сотен строк, при этом у вас будут уходить часы на рефакторинг. Какой из этих путей лучше?
Часть ответа состоит в том, что вы должны уметь работать и так и этак. Общая тенденция TDD очевидна – чем меньше шаги, тем лучше. В данной книге мы занимались разработкой маленьких тестов на уровне отдельных фрагментов программы. Однако некоторые программисты экспериментируют в области разработки программ, исходя из тестов на уровне всего приложения.
Если вы только приступаете к освоению рефакторинга, вы должны двигаться маленькими шажками. Процесс ручного рефакторинга чреват ошибками. Чем больше ошибок вы наделаете, тем меньшим будет ваше желание выполнять рефакторинг в дальнейшем. После того как вы 20 раз проделаете рефакторинг малюсенькими шажками, можете приступать к экспериментам по удлинению этих шажков.
Автоматизация существенно ускоряет процессы, связанные с рефакторингом. То, что раньше требовало выполнения 20 маленьких шагов вручную, теперь становится единственным пунктом в меню. Количество изменений, выполняемых в ходе сеанса рефакторинга увеличивается на порядок, и это неизменно сказывается на качестве. Когда вы знаете, что в вашем распоряжении великолепный инструмент, вы становитесь более агрессивным при выполнении рефакторинга. Вы пытаетесь ставить больше экспериментов и смотреть, какой способ структурирования кода лучше.