Re: Ambiguous Refactoring Solution

See if there are any members that are often used together in methods. These
clumps of members could be candidates for splitting the class into several
smaller classes.

What about concerns? Does the class have one or several identifiable
concerns or responsibilities? Each of these could be split into individual
classes.

Otherwise, I might start with some of the longer methods, and maybe see if
they can be split off into separate classes.

Are there any methods that both modify state, and query it and return a
value? These could first be split into different methods, then you can look
for member clumps or long methods again.

Any long if chains or switches? You could refactor these to a state or
strategy pattern.

Without seeing the class it is difficult to be more specific.
Sometimes I look at the list of anti-patterns on wikipedia, and see if any
of them apply, and try to come up with my own way of refactoring it away.

On Tue, Sep 22, 2009 at 06:08:20AM -0000, bryanedds 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
> 


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

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/