Лекция: MOVE METHOD (ПЕРЕМЕЩЕНИЕ МЕТОДА)
Каким образом метод можно переместить в hodoc место, где он должен находиться? Добавьте его в класс, к которому он должен принадлежать, затем обратитесь к нему.
Как
1. Скопируйте метод в буфер обмена.
2. Вставьте метод в целевой класс. Присвойте ему подобающее имя. Отхом лидируйте его.
3. Если внутри метода происходит обращение к изначальному объекту, добавьте в метод параметр, при помощи которого внутрь метода будет передаваться изначальный объект. Если внутри метода происходит обращение к переменным*членам изначального объекта, передавайте их в виде пара метров. Если внутри метода перемен и ы м • членам изначального объекта присваиваются значения, вы должны отказаться от идеи переноса метода в новый объект.
4. Замените тело изначального метода обращением к новому методу.
Зачем
Эго один из моих самых любимых рефакторингов, выполняемых в процессе консультирования. Дело в том. что он наиболее эффективно демонстрирует исправил ьные предположения относительно дизайна кода.
Рефакторинг Move Method (Перемещение метода) обладает тремя важными преимуществами:
· Очень легко увидеть необходимость применения этого рефакторинга. при этом не требуется глубокое понимание смысла кода. Как только вы увидите два иди больше сообщения, адресованных другому объекту, значит, можно смело приступать.
· Механика выполнения рефакторинга быстра н безопасна.
· Результаты зачастую приводят к просветлению. «Но масс Rectangle не выполняет никаких вычислений… О! Теперь я вижу. Так действительно лучше.»
34. Понятие рефакторинга. Рефакторинги «Метод в объект», «Добавление параметра», «Параметр метода в параметр конструктора».
В рамках TDD рефакторинг1 используется интересным образом. Обычно рефакторинг не может изменить семантику программы ни при каких условиях. В рамках TDD условия семантики формулируются при помощи тестов, которые уже срабатывают. Таким образом, и рамках TDD мы можем, например, заменить константы переменными и с чистой совестью назвать эту процедуру рсфакторин- гом, потому что набор срабат ывающих тестов при этом не изменился. Однако набор срабатывающих тестов может состоять всего из одного теста. Возможно, семантика программы должна описываться большим количеством тестов. Возможно также, что некоторые из этих потенциальных тестов в результате выполнения ^факторинга перестали бы срабатывать, если бы они существовали. Однако их пег. поэтому мы о них не беспокоимся.
Отсюда следует, что на программиста, работающею о стиле TDD, возлагается важная обязанность: он должен иметь лопаточное количество тестов» описывающих семантику программы. Достаточное по крайней мере настолько, настолько он может судить на момент завершения работы над кодом. Необходимо понимать, что рефакторинг выполняется не с учетом всех существующих тестов, а с учетом всех шзможнмх гсстов. Фраза наподобие: «Я знаю, что там была проблема, но все тесты сработали, поэтому я посчитал код завершенным и интегрировалсто и систему», — не может считаться оправданием. Пишите больше тестов.