Есть ли формальное определение для «рефакторинга»? - PullRequest
8 голосов
/ 19 ноября 2008

Кто-нибудь знает способ определить рефакторинг более формально?

UPDATE.

Рефакторинг - это пара R = (pre; T), где pre является предварительным условием, что программа должна удовлетворять, а T - преобразование программы.

Ответы [ 4 ]

3 голосов
/ 19 ноября 2008

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

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

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

Интересные вещи. Надеюсь, это поможет.

2 голосов
/ 19 ноября 2008

Интересно отметить, что большинство рефакторингов идут парами:

  • Добавить параметр - Удалить параметр
  • Извлечь класс / метод - встроенный класс / метод
  • Поле / метод подтягивания - Поле / метод подтягивания
  • Изменить двунаправленную ассоциацию на однонаправленную - Изменить однонаправленную ассоциацию на двунаправленную
  • ...

Применение двух рефакторингов пары является нулевым преобразованием.

Для пары рефакторинга R, R ':

R '(R (код)) = код

2 голосов
/ 19 ноября 2008

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

поэтому мы не можем просто утверждать, что преобразование рефакторинга T в программе P имеет одинаковые свойства R до и после рефакторинга, но свойства R 'реорганизованной программы P' должны быть по меньшей мере эквивалентны R

given program P implies R
refactoring transformation T(P) produces P'
where (P' implies R') and (R' is equivalent to or subsumes R')

мы также можем утверждать, что входы и выходы остаются неизменными или эквивалентными

но, следуя вашему примеру, возможно, мы хотим определить преобразование рефакторинга T как 4 кортежа P, I, O, R, где P - исходная программа, I - входные данные и / или предварительные условия, O - выходные данные. и / или постусловие, и R - преобразованная программа, затем утверждают (используя временную логику?), что

P:I -> O

сохраняется до преобразования

T(P) -> R

определяет преобразование, а

R:I -> O

сохраняется после преобразования

моя символическая математика ржавая, но это общее направление

это сделало бы хорошую магистерскую диссертацию, кстати

0 голосов
/ 19 ноября 2008

Ну не напрямую, а в денежном выражении - могу сказать да. Я не могу придумать уравнения по этому поводу:)

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

...