Re: Ambiguous Refactoring Solution

I agreed with Peter's comments, if you don't have immediate issues, bugs or new requirements, just let it sit there. You will know what the direction is when it comes the time you see a need to refactor it.

Regards,
Sam




________________________________
From: Peter Bell <[email protected]>
To: [email protected]
Sent: Tuesday, September 22, 2009 5:42:01 AM
Subject: Re: [refactoring] 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" <bryanedds@yahoo. com> 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]


   

[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/