Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Re: refactoring

Expand Messages
  • Ron Jeffries
    ... Well, yes. And ... just /what/ is functional behavior ? I can refactor a program in such a way as to make it run for a year instead of a millisecond. Is
    Message 1 of 129 , Oct 1, 2005
      On Saturday, October 1, 2005, at 3:48:27 PM, Michael Feathers wrote:

      > Philosophically, yes, it can go that way, but the def of refactoring is
      > is about functional behavior, not memory or performance. Altering the
      > the execution path doesn't change functional behavior and adding new
      > classes and methods doesn't either unless there is a current attempt in
      > the code to call them up via reflection.

      Well, yes. And ... just /what/ is "functional behavior"? I can
      refactor a program in such a way as to make it run for a year
      instead of a millisecond. Is that "functional"?

      The reflection example is an interesting one ... it shows that we
      could in fact write a program such that nothing we would normally
      call a refactoring would be one. Take, for example, a program that
      prints the number of classes and methods in itself. In one sense it
      works after "refactoring" ... except that it gets a completely
      different (albeit in some sense correct) answer.

      My point was, and remains, that as we refactor, we have in mind
      which "behavior" we intend to preserve, and which we do not. The
      notion is analogous to the mathematical metaphor that we all share,
      but as Don Roby has pointed out, it's not exact.

      Furthermore, when we refactor, we have changed what the program
      /is/, even if we have not changed [some more or less narrow subset]
      of what it /does/. It's a different program, with different
      possibilities, different ways to be used.

      An algebraic factoring, as far as I know, always "works", because
      the meaning of "works" is so narrow: something like "given any real
      numbers in the range of the function, both expressions calculate the
      same value." Even then we have to be careful, lest we insert a
      division by a number that is potentially zero, or an even root of a
      number that is negative. In use, as opposed to theory, even
      algebraic refactorings are chosen by intent, to accomplish some end.

      A code [re]factoring is trickier. Although it seems to be as
      formally defined as the algebraic one, it is driven by intent, even
      more so than the algebraic ones are.

      Now, frankly, I think that none of this matters in real life.
      Refactoring is a toolbox of code transformations which we choose,
      using our intelligence, to accomplish goals which we also choose.
      Its formal definition is perhaps quite useful to a few, but its
      practical application as part of software development is, to me,
      more valuable.

      Ron Jeffries
      Learn the principle, abide by the principle, and dissolve the principle.
      -- Bruce Lee
    • aacockburn
      ... Thanks - I was typing fast and my mind went blank. Alistair
      Message 129 of 129 , Mar 6, 2008
        --- In extremeprogramming@yahoogroups.com, Tim Ottinger <linux_tim@...>
        > "... of Illinois" (at Urbana/Champaign)

        Thanks - I was typing fast and my mind went blank. Alistair
      Your message has been successfully submitted and would be delivered to recipients shortly.