Developers tend to abuse design patterns and software standards. One such paradigm is Coding for an interface.. When writing daos, the first thing that the book says is “write an interface first”. Good, I write an interface and a hibernate implementation.Then I write another interface and another implementation. I add a method here and a method there and this continues with 30 interfaces and 30 implementations. When you look back after 6 months, you question, “why did I write an interface in the first place and why am I bookkeeping the two classes in keeping them in sync”
When the design standard first came in, it was assumed that you have multiple implementations of dao and you might change your ORM strategy or JDBC implementation. But lets be practical – Will you change your ORM implementation from Hibernate to Toplink or HibernateClone in the future? Will you?
Do you think a method like save (myobject obj) will have the same signature for both JDBC and ORM implementations? Take this – JDBC method signatures can never be the same as ORM method signatures, so why are we having an interface? I still could unit test a dao with Spring’s mock dao implementations, so you still dont need an Interface to exist.
Having a dummy interface just because you want to stick to a so called ‘standard’ doesnt make sense to me.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
5 Comments
I agree with this in general, it does seem like a real waste. Of course you can generate the interface and never look at it again, but why bother?
Well, what about generating a common interface that can be used by numerous DAOs?
Also, I use EasyMock for unit tests, and it requires an interface to use.
And what about frameworks such as Spring, I believe they assume an interface exists.
Programming to interface is a powerful design pattern, I’ve used it to my advantage in several situations and I can show you why it’s valuable. But I agree it seems like code proliferation in its current popular incarnation, the Hibernate>DAO>Service layer “pattern”.
having a top level AbstractDao or interface helps specially if you have a hibernate implementation (extend a HibernateDaoSupport) – save, getById kind of methods could go in here
Nonsense!
More interfaces! More Factories! More I say! More!
There is no such thing as over-designing!
RTC!
Interfaces and Factories are definitely good, the post was about understanding the rationale behind interfaces. There are sometimes, we dont absolutely need one and the above is one such example!
Sorry. I forgot to add a
after my post.
Post a Comment