Friday, August 15, 2008

Don't handicap my objects!

I've been doing some reading today and I keep running into a theme, that bothers me. I keep running into this idea that the functionality of individual classes should be limited so that if, for example, the database is changed, its effect is limited.

On the surface, this seems like great advice, and I honestly think that the intent correct. The problem I have is that the authors I've been reading have either not been going deep enough into their proposed solution, or they're missing an obvious solution that would make everyone's lives easier. Instead, it seems that they want to trade away the logical grouping of functionality within objects to avoid ripple effects when making changes. Ripple effects are bad and we need to avoid them for code to be maintainable, I just don't think we need to make that trade in this situation.

In this situation, you can have your cake and eat it too. So you don't want your TinyWidget class to have code to look up its price in the database that has to change when you go international and now you need to look up the price in dollars for Americans and pounds for Brits. That's great! But instead of taking the GetPrice function away from TinyWidget and putting it in the DatabaseAccess class, why can't TinyWidget.GetPrice just be a thin wrapper over DatabaseAccess.GetPrice?

Don't handicap my objects in the name of flexibility, create flexibility by encapsulating functionality in low-level objects and using thin wrappers in the higher-level objects.

No comments: