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

[XP] Re: refactoring

Expand Messages
  • Donald Roby
    ... For the record, I like to think of this as a mathematical thing. I can t help it - that s the way I think. Because of that, my natural inclination is to
    Message 1 of 129 , Oct 1, 2005
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, Ron Jeffries
      <ronjeffries@X...> wrote:
      > Chet and I were discussing this interesting thread today, at the
      > Brighton library.
      >
      > We reflected on the notion that a refactoring is a code change which
      > is "behavior-preserving".
      >
      > In the interest of deconstructing even this elementary definition,
      > we would point out that few, if any, so-called refactorings are
      > fully behavior-preserving.
      >

      For the record, I like to think of this as a mathematical thing. I
      can't help it - that's the way I think. Because of that, my natural
      inclination is to separate the concept from the intent of improving
      design. But that's not your point here, so I'm not going to worry the
      issue here. Maybe I'll hop to a different part of the thread later.

      The present discussion does at any rate depend on the definition of
      yet another word - "behavior".

      Opdyke's thesis says:

      "Refactorings do not change the behavior of a program; that is, if the
      program is called twice (before and after a refactoring) with the same
      set of inputs, the resulting set of outputs will be the same."

      This is not phrased in mathematical language, but is essentially a
      mathematical concept linking programs with functions. A program is a
      way of defining a function that accepts a specific set of inputs and
      returns a specific set of outputs.

      So "behavior" is defined functionally, and for a code change to be
      "behavior-preserving" is an equivalence relation meaning that the code
      before and after the change define the same function.

      Functions can be combined in quite a few well-defined ways, and can be
      factored into constituent parts, frequently in several ways.

      Programs can be combined and decomposed as well, and for the concept
      to be of any value in programming, this must be included in the
      concept. This is an obvious connection in functional programming, but
      can be made in OO programming as well (or indeed, in the paradigm of
      your choice). A single call to an object's method can be construed as
      a program with inputs being the initial state of the remainder of the
      system, including any parameters supplied, and outputs being the
      ending state combined with any return values.

      This discusion may of course be somewhat context-sensitive... Some
      things certainly work much better in the ideal and infinite world of
      mathematics than in the slightly more concrete and finite world of
      computing.

      > A refactoring is always /chosen/, to preserve some behavior, and
      > generally NOT to preserve other behavior. There is some kind of
      > "surface" of behavior that we want to preserve, but there are other
      > behaviors that change, about which we may be less concerned, such
      > as:
      >
      > - the memory footprint of the program will change;

      Certainly in a finite system, this is part of the state, and this is
      the reason all the math doesn't quite line up to reality. If the
      footprint exceeds capacity, then despite all the math and logic being
      correct, the system will break.

      Of course, if you get pedantic enough, even this might be managed by
      more detailed math, but it would be pointless, and things we naturally
      want to think of as refactoring might fail to qualify. I'm not going
      to suggest we sacrifice common sense at the altar of mathematical purity.

      But as you note, it frequently is of less concern.

      > - the execution path of the program will change;

      This isn't part of the externally visible behavior and shouldn't
      matter, except possibly as it affects memory and speed.

      > - the speed of the program will change;

      Think of something as simple as N^2 = 1 + 3 + 5 + ... + (2*N -1) with
      N a positive integer.

      I'd certainly want to regard the shift from one version of this
      computation to the other as a refactoring, since the function is the
      same regardless, but there's likely a speed variation, and for large
      N, it's probably large. It's pure algebra, and little to do with
      machines.

      In the imperfect world of finite computing, it may also be that
      failures such as overflows are different between the two.

      Again, by regarding the word size as part of the state, and phrasing
      the math in context of a finite ring, the overflow issue could be
      dealt with and we could know what is truly behavior-preserving with
      respect to overflow, but it's not worth getting that formal. The
      speed is probably an honest trade-off anyway, and heavily
      machine-dependent.

      > - the program may have new public classes and methods;

      If these classes and methods have no effect on what outputs the
      program produces for given inputs, that matters not at all.

      > - some methods may change behavior, though others may not;

      Certainly, but that's internal behavior. You do have to decide which
      program's behavior is to be preserved.

      > - and so on ...
      >

      You choose what subprogram you're working on, and if you want to call
      it a refactoring it should preserve the behavior of that subprogram.
      The fact that it's impossible to do it perfectly on a specific finite
      machine is bothersome, but doesn't for me change the value of the
      idea. And the idea is a mathematical equivalence.

      Frankly, if refactoring doesn't include behavior-preservation, I'd
      rather just call it code change. Refactoring needs the concept of
      functional equivalence to have any value for me.

      > So. Dance some angels on that.
      >

      We can dance many angels. If you've got a couple pins, we can
      probably divide them sensibly. And we probably have some choices in
      how we divide them.

      - Don Roby
    • aacockburn
      ... Thanks - I was typing fast and my mind went blank. Alistair
      Message 129 of 129 , Mar 6, 2008
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, Tim Ottinger <linux_tim@...>
        wrote:
        >
        > "... 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.