October 12, 2007

...Learn TDD with Codemanship

Reused Code Is Less Likely To Need To Change

Guillaume Bertrand, who you may recall solved the OO Design Challenge by creating a bone fide refactorbot to find the optimum package configuration, has quite rightly pointed out that my last post about why abstractions are less likely to change doesn't make total sense.

And that's for good reason. It doesn't make total sense because I hadn't totally thought it through. It was just my usual handwaving and random gesticulating. But I'm instinctively finding it hard to let go of this idea that code that gets reused more is less likely to change.

In my replay to Guillaume's email, I tried to articulate what it is I'm actualy thinking - and it's tough, because the idea is still blurry and not fully-formed.

I told him:

I am proposing that code that is reused is less
likely to be required to change. That's not because more code depends on
it, but simply because when things are reused, that suggests they are more
generally useful.

Take a class that calculates the sum of 2 + 2. That's only reusable in
situations where we want add those two specific numbers together. Now
consider a class that can any two numbers - X + Y. That's applicable in
more situations, and therefore - I suggest - more likely to be reused more

I can imagine if I was doing very, very strict TDD I might write a class
that adds 2+2 for one specific need that I had then. Looking at the code,
I might notice that the class I write is only used once. When I then have
a need to add 2 + 3, I modify my class to handle both of those scenarios.
Then it might be reused twice. Then along comes a need to add 3 + 4. And
I modify it again, and it gets reused a 3rd time. And so on. Eventually, I
have a class that can add any two numbers, which is reused many times. I
am suggesting that widespread reuse is evidence of wider applicability
(greater generalisation, I think).

A bit of set theory then makes me think that there are many more needs
that 2+2 *cannot* address than X+Y, and therefore a muich greater
probability that a need will arise that will require a change to the code.

Which is all a bit head-scratchingly handwavy, at the moment. But that's my
thinking - wider reuse suggests less possible needs that the code doesn't
already satisfy, which means a lower probability of a new need forcing a
change to that code.

So there you go; clear as mud.
Posted 13 years, 1 month ago on October 12, 2007