I have a strange coding habit.
Sometimes I need to create a class. Say I need to have a dog. So I create this dog class, and make it bark. Then I think to myself, what if I wanted to create a cat? How would I do that. Throw in an Animal class, and subclass it, making sure that each animal will have a correct sound. And since I’m doing that, I better make sure that I can define whether the animal is domesticated, 4 legged or 2 legged, big or small, or what colour it is too. All inside a fully versatile package, together with all the error detection anyone would ever need, and custom functions.
But all I wanted was a dog that barked.
Does anyone ever suffer from this “compulsive versatility” your applications or classes must have? When all you wanted was something that does a specific thing, and instead you build a full encapsulated class brimming with methods and functions that you probably won’t use, but others might?
I bring this up because, as some of you may have noted, I’ve been working on using WordPress as a CMS, for Flash and AMFPHP. And Patrick Mineault of 5etdemi, and developer of AMFPHP, asked for volunteers to create a package to integrate WordPress and AMFPHP. Now, as much as that sounds good and all, but for my purposes, I don’t need a full package, and I probably won’t finish it. Maybe its my self-perceived quality of work doesn’t seem up to scratch.
Well, hope I can keep at it. The other bad habit I have is losing steam really quickly.
I sometimes suffer from compulsive versatility. I once tried to create a 3d package and wound up spending about 2 weeks just adding vector math that I never even needed. It can be very satisfying to have a completely spec’d out class with everything working but for the most part it’s a bad habit to have.
The only times when you really need to fully build out a class or package in my opinion is when you’re building a library or something else that will be frequently reused by other coders. Even then it’s important to stick to your core functionality and not start building in unnecessary elements. Error handling and validation might be an exception if it’s prone to failure.
A technique that might help your design is to think of everything from an interface-oriented perspective. Design your program with the interface in mind which may help you focus on the functionality that you need to make your program work rather than the robustness of your classes. In this case, all you need is ISoundGenerator. You can deal with IDomesticatable, IMultiLeggedCreature, ICreatureWithSize, and IColored when you get to them.