Re: Refactoring wishlist

>
> Do you have refactorings for Java that you wish to get from Santa by mid
> December?
>

Yes. But I'd like to approach this from a different perspective.

Instead of viewing refactoring as an ad hoc process, I'd like to propose
that it is - or should be - a flow. I just don't refactor piecemeal, a
little change here, a little change there, just for the heck of it. Instead
I refactor based on overall flow with a final goal in mind. I'd like the
refactoring tool to support that *flow* if possible, not just the individual
refactoring operations.

My typical refactoring flow is:

1) Start with a big ugly class
2) Mark as many methods private as I can


   - I do this to clearly show what the class needs to provide to its
   current callers, i.e. make the encapsulation boundary explicit.
   - I currently do this manually, so refactoring operation #1: Make as many
   methods private as possible for a given class.

3) Extract as many private methods as I can


   - I do this to simplify the code in as many existing methods as possible.
   - Simplification makes it possible to see the micro-architecture of the
   class; how it fits together; the structure of the methods; how they
   interact; etc.
   - This is refactoring operation #2: Extract private method.

4) Look for patterns in the private methods


   - well, this is the step where magic happens. The private methods may
   have a pattern in the signatures or in their use of member variables or
   ....something. Something that is that suggests a subset of the private
   methods somehow hang together. The methods are cohesive around some concept;
   it suggests that a class can be extracted.
   - Refactoring operation #3: Extract class; make all it's methods public;
   adjust the original class to use the new class and methods.

5) Compare the newly extracted class with the remainder of the private
methods. Move additional methods to the new class if possible.


   - The newly extracted class will have an intent, a purpose, a conceptual
   core. (Or at least, it better have! If it doesn't, undo the last refactoring
   and go back to step #4.)
   - Other private methods in the original class might fit into that
   conceptual core. Move them over to the newly extracted class.
   - Refactoring operation #4: Move private method to other class.

6) repeat #3, #4 and #5 until they can't be done any more.

   - Note I usually repeat the overall process against the newly extracted
   class, if possible.

That's it. The goal is to extract classes until each is singular, i.e. one
and only one purpose.

The only other refactoring operations I would use are:


   - rename variable
   - rename function
   - rename class

I would probably do these for code readability; for explanatory purposes;
for clarification purposes. They would probably be done throughout steps #2
thru #6 above as I discovered how everything fits together.

I'm sure other folks have their own refactoring workflows...

John


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/