I'm geek-famous again!

So if I bribe Craig Shoemaker with $5 every time he posts an episode of Polymorphic Podcast, I get mentioned on the podcast, and even on the blog. Being a Tivo / Podcast evangelist (short version: thou shalt not listen to commercials) it's weird how your sense of "famous" completely changes. In my weird little universe, Craig Shoemaker, Scott Hanselman, and the Java Posse are more famous than Matt Lauer or Hillary Duff. (Oh, excellent! I'm so unplugged that I didn't even get the name right... I was thinking Lindsay Lohan.)

Anywho, so Craig interviewed Miguel Castro again, and among other things, they talked about the whole abstract base class vs. interface decision. I am apparently in a minority here, but I prefer both. In all cases, I pass around the least-specific interface or base class that I need. (Does that parameter need to be List, or do you just need IEnumerable?)

I always think in terms of avoiding option-limiting decisions. So if I'm going to make a base class or interface for something, I want both. I start with an interface and that is the type that I always pass around. I make a base class that implements that interface, and that may even end up being the only thing in the world that ever implements that interface, but I've left myself an out -- the option to change my mind without ripping the guts out of everything.

When I start designing stuff this way, I get a lot of pushback, though. And usually the argument involves the phrase "overengineering". And then my response is usually that it won't feel overengineered if you see it everywhere and it just becomes the knee-jerk implementation that you always use. And it's really not a big deal. When you want to pull up some code into a base class, go ahead and do it. Then just go one step further and pull those signatures up into an interface.