Re: TDD and Refactoring

From: Ron Jeffries (ronjeffries_at_REMOVEacm.org)
Date: 12/24/03 

Date: Wed, 24 Dec 2003 10:49:43 -0500

On Wed, 24 Dec 2003 09:12:28 +0000, herwin@theworld.com (Harry Erwin) wrote:

>3. The class instances that are displayed in the GUI needed to hang
>around, so many of the polymorphism strategies had to be implemented
>using State/Strategy patterns. This produced an inheritance hierarchy
>explosion.
>
>4. Unit testing the math turned into a serious headache, especially with
>all the special cases. The business logic test case suite looks like
>it's headed for 100+ individual test cases. This is for a single use
>case.
>
>5. Replacing temps with queries produced method explosions in the key
>classes of the business logic.
>
>6. I was hoping careful refactoring would reveal some different ways of
>organizing the design. The complexity explosions made it very difficult
>to see the forest for the trees.

It would be very interesting to see more about this, especially as the system
evolved. As complexity increases, I'd expect that there is something to do about
it early on, so that one doesn't get an explosion. So I'm wondering whether
certain code smells were not detected in time. There are many more refactorings
besides Extract Method, as you know, and Extract Method alone does tend to add
trees to the forest.

I'm also wondering why there were special cases in the math. I ask because good
math seems to always be quite general, with very few special cases. On the other
hand, 100 test cases might be a perfectly reasonable number, depending on what
the app is. Even a thousand might be reasonable.

Replacing temp with query, I would say, does not increase complexity: there's
exactly one query per temp. Perhaps I'm missing something.

Also, if there are a lot of temps wanting to be around, there might be some
classes wanting to be extracted. Did you observe that need, and respond to it?

It's entirely possible that you have ended up with the best possible system, but
it sounds like your intuition says otherwise. Your intuition is probably right.
So what would make the system better, and why didn't the refactoring approach
lead you there?

You have had an interesting experience -- it would be great to read the article
or book that explains it all. What more have you the time to tell us? 

-- 
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

Relevant Pages

  • Re: JSH: One of the great relations?
    ... but must not that complexity must grow by time to avoid repetition of old math. ... about the obsolete work of dead people who used to do ...
    (sci.math)
  • Re: ...Why Space Solar Power should be the future of NASA!
    ... I spent the four years needed to get a math degree. ... predicting a stock market crash is like ... You can't even grasp the core idea in complexity science which allows ... is now analogous to uncertainty. ...
    (sci.space.policy)
  • Re: SproutMethod.pdf
    ... After a deep breath, and honest reflection, most should agree that whatever ... created OO in the first place to reduce complexity. ... existing sw engineering paradigms like the formal grammars, ... of the math and parts of the world the math is being applied to. ...
    (comp.object)
  • Re: A Question about Number Theory - A Newbie
    ... Does it have any complexity? ... Number theory is an advanced field of math, ... particularly useful in cryptography are prime numbers, ... numbers, and modular groups. ...
    (comp.security.misc)