Re: Ambiguous Refactoring Solution

+1. I understand that as you're asking the list you're probably  
looking for specific refactoring strategies, but I usually find that  
as a general rule when I'm not seeing a path, I'm often trying to walk  
through a hedge. I like to let both the code and the refactorings  
emerge from user stories. If I don't feel a cohesive  "extract  
subclass" or similar refactoring, often I'll just live with a slightly  
larger class file. If I never change the file again, no harm, no foul.  
If I do, it'll probably be to add behavior that will point in the  
direction of an appropriate refactoring.

Best Wishes,
Peter

On Sep 22, 2009, at 7:31 AM, Michael New wrote:

> If there's no problem, why refactor? Why worry?
>
> If it's a large-ish class with a lot of small methods that all make
> sense, perhaps it's perfect?
>
> Mike
>
> Sent from my iPod
>
> On 2009-09-22, at 2:08 AM, "bryanedds" <[email protected]> wrote:
>
> > My issue is that I have a class that is 613 lines of C++ code. This
> > is a very fat class, but it's moderately cohesive. I would like to
> > refactor it to address the size issue. The problem is that I don't
> > have a specific enough problem that the refactoring will solve. This
> > seems to ambiguate the refactoring solution. For example, I could do
> > an extract subclass. That would be a simple solution. Or, I could
> > extract a strategy class that the original class delegates to. This
> > is more complex, but will probably be more future proof. Or, I could
> > extract a mediator class. There are many choices.
> >
> > Now, usually I have an immediately pressing context from which to
> > derive a refactoring solution. That context is usually of reuse. I
> > can ask myself, "how do I refactor this class in order to best
> > facilitate reuse of its key elements?" The refactoring solution
> > often very neatly falls out of the reuse context. Such a context is
> > absent here.
> >
> > I could sit and theorize about what I would do in a future reuse
> > context. But that seems to be irresponsibly speculative.
> >
> > Any one have any ideas on how to refactor when the usual driving
> > forces are absent?
> >
> > - Bryan
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
> 



[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:
    mailto:[email protected] 
    mailto:[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/