By throp
via bennorthrop.com
Published: May 30 2008 / 06:11
I need to butt heads with conventional coding wisdom for a minute. We've all heard that it's good to program to interfaces and not implementations, but I'd like to argue that in most cases this actually buys us very little. In fact, it often just causes code bloat and developer frustration. There, I said it!
Comments
warpedjavaguy replied ago:
Do interfaces buy us anything? Yes. Abstractions!
fmoidu replied ago:
Voted down because the article basically says that sometimes interfaces aren't useful. Yes, that is true. Not all things are perfect all the time.
The article focuses on implementation specifics to argue why an abstraction tool is not worthwhile. The gain from interfaces is to allow implementation to be abstract, not to reduce the amount of implementation in all cases.
For example the Iterator interface is a powerful common case for interfaces. The article does have thought behind it, but I find that its main example is poor.
wytten replied ago:
Better safe than sorry
hal10001 replied ago:
The problem is that programmers ignore the simple fact that abstraction through an interface is an evolution of sorts. Most books and tutorials discuss an interface as an abstraction when two completely separate concrete classes need to share behavior that is by nature abstract to both (or many) of them. The answer is to code to an interface. Instead you get a top-down approach that simply adds unnecessary bloat. Think of the animal kingdom diagram as a reference. Scientists did not create segmentations (animal, reptile, fish) and then define common characteristics. They defined common characteristics, and then worked upwards to an abstraction.
throp replied ago:
Just defending my own article;) ...I think I probably represented my argument poorly. Essentially, I was just trying to say that using the principle of "program to interfaces" shouldn't be dogmatically applied. Unless there's a reasonable expectation that you'll at some point need another implementation, in my opinion, adding an interface is just excess complexity. Loose coupling comes at a cost...
Yes...the example I gave is a complete straw-man;)...but nevertheless I see it very often...
WarpedJavaGuy - When there's only ever one implementation to an interface, where's the abstraction?
warpedjavaguy replied ago:
The abstraction exists in the interface regardless of the number of implementations. The real problem with the "classic" DAO strategy is that it requires you to define multiple DAO interfaces, one per entity, where each one has only one implementation. That is why it is a straw-man!
brian.papa replied ago:
I most agree with this statement:
"it's harder for developers to step through code (e.g. F3 in Eclipse won't work!)"
However this is something that an IDE could address in the future.
,
Voters For This Link (14)
Voters Against This Link (15)