Refactoring in Tunes

[btanksley@hifn.com]

> From: Laurent Martelli [mailto:martelli@iie.cnam.fr]
> Subject: Re: Refactoring in Tunes

> >>>>> "bill" == btanksley  <btanksley@hifn.com> writes:

>   bill> you're asking for.  "Refactoring" is generally used to
>   bill> indicate the process of changing the way code put together in
>   bill> order to produce a better fit to a better design.  In other

>   bill> Refactoring in this sense cannot be helped by a runtime
>   bill> system, but it can be helped by a language designed for it.
>   bill> Forth is well-suited for refactoring because of its absence of
>   bill> explicit variables; Java works well because of it moderately
>   bill> strong compile-time typechecking (to help the programmer catch
>   bill> typos written during the refactoring); and Smalltalk works
>   bill> well because there are automated tools to performs some of the
>   bill> most common refactorings.

> I can't what makes C more difficult to refactor than smalltalk. I

I didn't mention C at all here.

However, let's take a look at it.  C has slightly stronger typechecking than
Smalltalk, so the C compiler will warn you of a few errors; however, C's
typechecking is weak enough that if you try to take advantage of it you'll
wind up letting a lot of errors slip by you.  Advantage: neither one.

Smalltalk has more possible refactorings: it's easy to make a "parameter
object" im Smalltalk, and it's hard in C.  It's even harder in C to do
refactorings which "split" a function which has internal state, but
Smalltalk (of course) has no trouble at all.  Strong advantage to Smalltalk.

Smalltalk wins versus C, all in all, because as an OO language it has many
more possible refactorings.  Smalltalk looks a lot worse than Java for
refactoring, but because Smalltalk is interactive, it's possible to get your
unit tests out of the way a LOT quicker, and this speed encourages frequent
refactoring, which makes the final design likely to be a LOT nicer.  In
addition, Smalltalk has tools for refactoring which are only beginning to be
developed for Java.

> think that refactoring does not only apply to OO languages. I see it
> as finding patterns which are used more than once. 
[snipped: example of finding redundant patterns, making them into a
function, and calling the function from both places]

No, that's function factoring, not Refactoring.  My "Refactoring" book calls
that "Extract Method".  Refactoring also includes the inverse of that --
"Inline Method".  A good coder should know how to do both refactorings;
sometimes you need to inline a method in order to get special behavior (or
because you made a poor choice of factoring earlier and now you have to
redivide your functions' functionality).

> When you're dealing with OOL, you introduce new base classes, but it's
> the same mechanism.

The full art of refactoring is about being able to change the design of a
program, not simply make it take up less space.  You accomplish that change
in two steps: first, you apply source changes which preserve the old
behavior but provide a more suitable class or function layout (these are
what Fowler calls "refactorings"); and second, you change the arrangement of
these new classes to provide your new behavior.

> Laurent Martelli

-Billy