Ambiguous Refactoring Solution

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/