Re: Ambiguous Refactoring Solution

I received so many responses that I couldn't pick one to respond to, so I will do a cumulative response here.

A couple of people asked if there were any smells present that called for a refactoring. I answer in the definite positive, most specifically a violation of the SRP. But a smell alone is not enough context to clarify which refactoring of the applicable subset to choose from. While the fissure at which to split the class is clear, the appropriate means to achieve that split allude me.

Multiple people have responded essentially with "don't do anything until more contextual forces arise". I am leaning toward this.

I do not have tests for the class. The reason is that I don't feel tests on this class will pay for themselves. But if I did create tests for it, one specific refactoring will make them easier to write. I have reservations about molding my code to fit tests, though. It seems arbitrary and possibly orthogonal to future forces that may arise.

The one though I had was this - do the simplest refactoring possible that will split up the class. The DTSTTCPW principle may be enough to disambiguate the situation. The simplest way to split the class, IMO, is to use the Extract Superclass refactoring. Inheritance seems to be the simplest way to split a class definition.

Please let me know more of your thoughts!

- Bryan

--- In [email protected], "bryanedds" <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/