Dr. Cedric In the House
Cedric has a new style on his blog (very nice) and an interesting new post on using Interfaces. In it he makes two interesting assertions: never supply an interface without a factory and "new" should only appear in factories. He's going to expand on the second one later, but the idea is that the first rule avoids this type of code:
IEmployee emp = new EmployeeImpl();
Woof, that's ugly, ain't it? Check out Cedric's site for the details.
I think probably everyone thinks I'm an idiot now because I "don't like interfaces", but that's not what I've been saying. I'm saying that I'm constantly running into overuse of Interfaces and this is the cause of the Impl's I'm always seeing (which I don't like). This example code above is a direct result of every class having an Interface whether it needs it or not. In my mind, if you create an interface that's used by only one class, you're overdeveloping. That goes for factories or any other pattern also. Write your class, and if you discover reusability, refactor it out as an interface.
Basically, you need to THINK in interfaces, but program in classes. In other words, think about your application in terms of reusuable parts, but don't start messing up your code with needless crap.
Now someone help me out, I'm starting to see posts about Test Driven Development (TDD) where they're talking about creating lots of interfaces. Is this true? Tell me it isn't so! I need some education on this topic...
-Russ