Главная Случайная страница Контакты | Мы поможем в написании вашей работы! | ||
|
Каким образом можно перейти от одного представления к другому? Временно дублируйте данные.
Как
Вначале рассмотрим версию «от внутреннего к внешнему». В рамках этого подхода вы вначале изменяете внутреннее представление, а затем меняете внешний
интерфейс.
1. Создайте экземплярную переменную в новом формате.
2. Инициализируйте переменную нового формата везде, где инициализируется переменная старого формата.
3. Используйте переменную нового формата везде, где используется переменная старого формата.
4. Удалите старый формат.
5. Измените внешний интерфейс таким образом, чтобы использовать новый формат.
Однако в некоторых ситуациях вам удобнее вначале изменить API. В этом случае вы должны выполнить рефакторинг следующим образом:
1. Добавьте параметр в новом формате
2. Обеспечьте преобразование параметра в новом формате во внутреннее представление, обладающее старым форматом.
3. Удалите параметр в старом формате.
4. Замените использование старого формата на использование нового формата.
5. Удалите старый формат.
EXTRACT METHOD (ВЫДЕЛЕНИЕ МЕТОДА)
Каким образом длинный сложный метод можно сделать простым в прочтении? Выделите небольшую часть длинного метода в отдельный метод и обратитесь к этому методу из длинного метода.
Как
Выделение метода на самом деде является несколько более сложным атомарным рефакторингом. Здесь я опишу самый типичный случай. К счастью, многие среди разработки поддерживают автоматическое выполнение этого рефакторнига. Итак, чтобы выделить метод:
1. Определите фрагмент кода, который можно выделить в отдельный метод. Хорошими кандидатами являются тела циклов, сами циклы, а также ветви условных опера юрой.
2. Убедитесь в том, что внутри эгого фрагмента не происходит присвоения значений временным переменным, обьявленмым вне области видимости, соответствующей этому фрагменту.
3. Скопируйте код из старою метода в новый метод. Откомпилируйте его.
4. Для каждой временной переменной или параметра изначального метода, используемого в новом методе, добавьте параметр в новый метод,
5. Сделайте так, чтобы в нужном месте старый метод обращался к новому методу.
Зачем
Я использую Extract Method (Выделение.метода), когда пытаюсь понять сложный код. «Значит так, этот кусок кода делает вот это. А этот кусок делает это. К чему мы там дальше обращаемся?* После получаса код выглядит гораздо лучше, ваш партер начинает понимать, что вы действительно оказываете ему помощь» а вы существенно лучше понимаете, что же все-таки происходи! внутри кода.
Я использую выделение метода для 70ix>. чгобы избавиться ог дублирования, когда вижу, что два метода обладают сходными участками кода. В этом случае я выделяю схожие участки в отдельный метод. (Браузер рефакторинги Smalltalk Rcfactonng Browser выполняет еще более полезную задачу: он просматривает код в поисках метода, аналогичного коду, который вы намерены выделить, и в случае, если такой метод уже есть, предлагает вале использовагь уже существующий метод вместо того, чтобы создавать новый.)
Разделение методов на множество мелких кусочков может зайти слишком далеко. Если я не вижу, кула идти дальше, я часто использую Inline Method (Встраивание метода), чтобы собрать код в одном месте и увидеть новый, более удобный способ разделения.
33. Понятие рефакторинга. Рефакторинги «Встраивание метода», «Выделение интерфейса», «Перемещение метода».
В рамках TDD рефакторинг1 используется интересным образом. Обычно рефакторинг не может изменить семантику программы ни при каких условиях. В рамках TDD условия семантики формулируются при помощи тестов, которые уже срабатывают. Таким образом, и рамках TDD мы можем, например, заменить константы переменными и с чистой совестью назвать эту процедуру рсфакторин- гом, потому что набор срабатывающих тестов при этом не изменился. Однако набор срабатывающих тестов может состоять всего из одного теста. Возможно, семантика программы должна описываться большим количеством тестов. Возможно также, что некоторые из этих потенциальных тестов в результате выполнения ^факторинга перестали бы срабатывать, если бы они существовали. Однако их пег. поэтому мы о них не беспокоимся.
Отсюда следует, что на программиста, работающею о стиле TDD, возлагается важная обязанность: он должен иметь лопаточное количество тестов» описывающих семантику программы. Достаточное по крайней мере настолько, настолько он может судить на момент завершения работы над кодом. Необходимо понимать, что рефакторинг выполняется не с учетом всех существующих тестов, а с учетом всех шзможнмх гсстов. Фраза наподобие: «Я знаю, что там была проблема, но все тесты сработали, поэтому я посчитал код завершенным и интегрировал сто и систему», — не может считаться оправданием. Пишите больше тестов.
Дата публикования: 2015-01-26; Прочитано: 219 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!