OdeToCode IC Logo

It's Design

Wednesday, January 26, 2011

If I come across this code:

if (widget.Price < 10.0m && widget.UnitsInStock > 100)
{ 
    // ... 
}            

Then the first thing I'll suggest is refactoring to: 

if (widget.IsEligibleForDiscount)
{
    // ...
}            

But It's Not Reusable!

"IsEligibleForDiscount will never be reused!", someone will shout. "Why do we go to the trouble if the logic is never reused?".

Ah, yes - but if we only use encapsulation as a means to generalize and achieve reuse, then we're not taking advantage of what classes, methods, functions, objects, and properties truly have to offer. As Kevin Henney once wisely said: "there is no such thing as reusable software, only software that has been reused".

But It's Trivial!

"Why go to the trouble of creating a one-line method or property?".

Yes, it is is trivial, but you can't measure the effectiveness of an abstraction by it's size,  or by the amount of effort required to create the abstraction. This is like measuring the impact of an animation by counting how many colors it uses. It's often the small, quick, subtle animations that improve usability and polish. Likewise, a good abstractions can be small and still improve the usability of the code.

But It's Bad For Performance!

Go away - and don't come back without hard numbers.

It's Design

You've probably worked on applications that have two types of objects - objects with data and object with behavior. The objects with behavior are mostly procedural scripts to manipulate the objects with data. Strings and integers dominate the codebase. The objects aren't part of an object oriented design, but part of a process decomposition.

Breaking out of design habits is hard - it takes deliberate practice, and depends on introspective moments.

We can debate in our minds if the refactoring make the code better or worse - but let's at least have the debate.