Re: Re: Ambiguous Refactoring Solution

Well, you said you were looking for an opportunity to use reuse to drive
your refactoring. A class that is thoroughly unit-tested is always used
twice (Once by the test, once by the production code.) Perhaps writing a few
unit tests will tell you what you need to know.

Also, it is irresponsibly dangerous to apply refactoring to production code
that has no test coverage. No matter how smart you are you can't know every
way that something could break (And no matter how many moves ahead you can
think, 613 lines of code in one class is a whole lot of moving parts.)

On Tue, Sep 22, 2009 at 3:53 PM, bryanedds <[email protected]> wrote:

>
>
> 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] <refactoring%40yahoogroups.com>,
> "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
> >
>
>  
>


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