This week's book giveaway is in the Java in General forum.
We're giving away four copies of Think Java: How to Think Like a Computer Scientist and have Allen B. Downey & Chris Mayfield on-line!
See this thread for details.
Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

DAO Pattern

 
neha sher
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why do we need to create interface and implementation both while using DAO pattern?
I understand advantages of using interfaces like functional abstraction, different implementations etc.
But in a project, when only one implementation class is needed at DAO layer, Do I need to create interface for that just because DAO pattern work like that?
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15274
37
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of the reasons to make an interface and an implementation of things like a DAO is because it makes testing the system easier. When running a test, you can easily replace the real DAO with a mock DAO object that doesn't really use the database, but gets data from a set of test data instead. The mock DAO would implement the same interface as the real DAO, and the system would talk to the DAO only through the interface.

Some people however overuse the interface - implementation pattern and make a separate interface and implementation for (almost) every class in their system. The disadvantage of that is that it unnecessarily complicates the system (besides the interface and implementation, you'd also need a factory that instantiates the implementation object, etc.).

Recently, at the conference of TheServerSide, I saw a talk by Adam Bien (a Java EE architect). His talk was about making lightweight applications with Java EE 6, and one of the things he talked about was exactly this subject.

You should only use patterns like interface - implementation - factory when they actually make sense; too many people use it even in cases when it's not necessary, just because they think it is a best practice, without thinking well enough about it.
 
Hauke Ingmar Schmidt
Rancher
Posts: 436
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesper de Jong wrote:Recently, at the conference of TheServerSide, I saw a talk by Adam Bien (a Java EE architect). His talk was about making lightweight applications with Java EE 6, and one of the things he talked about was exactly this subject.


Yes... I read a blog entry by Adam Bien where he argued against the use of interfaces. It was a little too extreme to the "don't use it" side for me. Maybe because he does not seem to be very enthusiastic about Spring, which encourages this massively, and is more interested in pure J2EE.

On a completely unrelated note: He is a strong advocate of Netbeans which got a decent navigation between overridden/implemented methods just in the latest release (6.9.1). Maybe the inconvenience of a tool influenced the decision for or against some patterns. (And yes, Java needs good tools to be fun. While it is possible to code Java with a text editor, I think it is a terrible and unproductive idea.)
 
David Byron
Rancher
Posts: 175
Clojure Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
neha sher wrote:Why do we need to create interface and implementation both while using DAO pattern? I understand advantages of using interfaces like functional abstraction, different implementations etc. But in a project, when only one implementation class is needed at DAO layer, Do I need to create interface for that just because DAO pattern work like that?

Do you need both an explicit interface and a class for the DAO? One way to answer the question is to answer this one: Do you need to enforce that interface on any other classes?

Here's a common arrangement. You have several DAOs. They have some methods in common, but each is distinctive. Push everything that is common to all the DAO implementations into an abstract base class that all the DAOs extend, and provide an explicit interface for the base class. This enforces the common factors on any other DAOs you create, but relieves the burden of DAO proliferation.

For an extremely simple app with only a single DAO and where there is no possibility of adding another, an explicit interface is superfluous.
 
neha sher
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks all for your reply. I got my answer
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic