Заменить Temp запросом

Он призван более полно раскрыть цель кода. В некоторых случаях им можно злоупотреблять, но маловероятно. например, вы можете обновить запросы о скидках 5% и 2% запросами, но в названии методов вы можете описать в названии причину скидки. помните, сегодня это может быть очевидным, но через 6 месяцев это может быть не так - как я уже сказал - дело не в том, что я забуду, а в том, когда я забуду.

  if (basePrice() > 1000)
     return bigTicketDiscount()
  else
     return regularDiscount()

double bigTicketDiscount(){
  return basePrice() * 0.95;
}

double regularDiscount(){
  return basePrice() * 0.98
}

Мне действительно кажется, что, делая это, вы помогаете достичь единой цели вашего исходного метода; Он больше не отвечает за расчет basePrice и скидки (или того, что он рассчитывает). Это пример того, как жертвовать некоторыми циклами ЦП, чтобы сделать код более удобным для сопровождения. «Потраченные впустую» циклы процессора, вероятно, не то, что вы заметите для одного, а также возможно, что компилятор может оптимизировать его (возможно, заметив, что метод относительно прост, и вместо вызова метода он вставляет фактический код (больше похоже на В любом случае, эти типы оптимизаций лучше оставить машинам, оставив людям работать над более чистым кодом.

Прочитав веб-страница на нем Фаулера, я не вижу преимуществ в том, чтобы делать это таким образом. Единственный возможный выигрыш - это изолировать выражение, которое может часто использоваться, в одном месте, но с этим лучше всего справиться:

    double basePrice = basePrice();
    if (basePrice > 1000)
            return basePrice * 0.95;
    else
            return basePrice * 0.98;

Фаулер не предлагает никаких объяснений, почему его исправленный код лучше оригинала, кроме как читать его книгу.

Я думаю, что большая часть полезности этого рефакторинга заключается не в его применении как таковом, а в качестве шага к методу извлечения, который является чрезвычайно распространенным и полезным. В тех случаях, когда локальная переменная мешает извлечению метода или усложняет его дополнительными параметрами, «замените временную переменную на подсказку», чтобы упростить извлечение метода. Также в этих случаях созданный метод запроса повторно используется двумя разными методами, которые являются результатом метода извлечения.

Есть еще кое-что о замене Temp запросом в книге рефакторинга, и это:

You may be concerned about performance in this case. As with other performance issues, let it slide for the moment. Nine times out of ten, it won't matter. When it does matter, you will fix the problem during optimization. With your code better factored, you will often find more powerful optimizations, which you would have missed without refactoring. If worse comes to worse, it's very easy to put the temp back.

Это рефакторинг, который важен, поскольку это рефакторинг в сторону единственной ответственности, это решение DRY fail!

Основная проблема с темпами (особенно в наивном коде, использующем длинные методы, длиной в сотни строк!) Заключается в том, что они являются изменяемыми, локальными состояниями. Очевидный риск (как обсуждал Фаулер?) Состоит в том, что кто-то может внести изменения в середине длинного метода и что-то сломать в конце. (Видели понесенные затраты)

Нет никаких тестов, у этого метода множество зависимостей - какой бардак! :)

Remove temp - это рефакторинг в сторону единоличной ответственности.

Пример - сегодня я обнаружил ошибку, связанную с передачей неправильная временная переменная в службу. Если я удалю temps (их несколько, все строки), эта ошибка (недосмотр) просто не может произойти.

Причина, по которой мой метод содержит временную переменную, заключается в том, что он выполняет работу, которой не должен ... и эта логика повторяется в аналогичных классах ... все ли это согласовано? НЕТ!

Удалив temp, я также реорганизую код в класс с соответствующей ответственностью, который можно на 110% покрыть несколькими простыми тестами.

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

Если я назову что-то дорогое, я верну результат как объект / агрегат значения. «Временный код», вероятно, должен быть усвоен агрегатом.

Так что удаление temp толкает вас на централизованную (единственную) ответственность -> SOLID!

Я сейчас перечитываю «Рефакторинг», и одной из причин является следующая цитата из конца Extract Method, стр.116.

Предыстория: он описывает, что Extract Method трудно, если код для извлечения использует локальные переменные.

Temporary variables often are so plentiful that they make extraction very awkward. In these cases I try to reduce the temps by using Replace Temp with Query (120). ...

Таким образом, один рефакторинг может зависеть от первого рефакторинга, который сам по себе неочевиден. Другой пример - Inline Method перед заменой Method with Method Object.

Вы (как первоначальный спрашивающий, так и Джеймс Карран) упускаете из виду, что в этом конкретном примере расчет не повторяется. Либо код идет вниз по одной ветви if и вызывает basePrice(), который выполняет расчет. Или код переходит в другую ветвь if, и там же выполняется расчет.

Умножение производится независимо, но все же только один раз. Как и во временной версии.

Да, хорошо знать, что запросы по умолчанию не кэшируются и что временные файлы по своей сути являются формой кеширования. В этом конкретном примере это различие не имеет значения. Преимущество кеширования (например, temps) состоит в том, что оно может обеспечить экономию цикла ЦП (не совсем в этом случае, если говорить о самом умножении, я имею в виду - с точки зрения вызовов, скачков стека и т. компилятор). Недостатком кеширования является то, что оно может дать вам устаревшие или неверные данные, если вы небрежны. Это в дополнение к определенным недостаткам темпов, которые упоминает Фаулер (что они локальны, как во времени, так и в лексике).

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

Вот тогда и пригодится обратный рефакторингу - «Заменить запрос на временный».