Why use interface in Dao design pattern or other design patterns

Question

Please see below components of a Dao design pattern:

Data Access Object Pattern or DAO pattern is used to separate low level data accessing API or operations from high level business services. Following are the participants in Data Access Object Pattern.

Data Access Object Interface - This interface defines the standard operations to be performed on a model object(s).

Data Access Object concrete class -This class implements above interface. This class is responsible to get data from a datasource which can be database / xml or any other storage mechanism.

Model Object or Value Object - This object is simple POJO containing get/set methods to store data retrieved using DAO class.

Why do we need an INTERFACE when we have a concrete class and why can't we use it directly? This might be a naive question but please help me get this thing clear. Not only in DAO design pattern but in other design patterns also use of INTERFACE is bit confusing. I agree this is related to code reusabilty and reduced coupling. But can anyone please explain a bit further.

Answer 1

Not only in DAO design pattern but in other design patterns also use of INTERFACE is bit confusing.

Interfaces is one of the best used concepts in Java. Let me explain this with an example: Say you designed a GPS device for car which looks into the map and automatically turns the car to the direction as seen in the map. This GPS device can be used in many cars like benz, fiat, etc. For each car, the mechanism of turning the left or right may differ depending on the implementation of the car system. So,these functions should be written by the car manufacturer and hence these methods are put in a interface, which is implemented by the car manufacture as per his car's implementation. The interface includes only a set of function declarations which are to be defined by the car manufacturer(In this case). Got it?

To learn more about interfaces and why they are useful, read this article.

My question is: Why do we need an INTERFACE when we have a concrete class and why can't we use it directly.

Among many other benefits that were pointed out in answers below, you can create many DAO classes for different data structers (derby db, huge stacks etc.), that implements DAO interface. The benefit is, that every class can be stored in DAO interface variable, its called polymorphism.

Answer 2

Actually its not necessary to have an interface when you have only one implementation. But there are certain situation where it is very practical that you dont have a depencecy to the concrete class:

• Testing your service that calls the DAO: You can write a mock DAO that behaves just as you need it in the test (e.g. simulat that there is no DB connection, which is hard to reproduce automatically)

• generate some Layers aoround your DAO. You could use AOP to generate caching or transaction handling around your DAO methods. In this case you have an object that implements the DAOs interface but has nothing to do with the original implementation.

• Switching the DB technology. If you switch from MySQL to DB2 you just need to write another implementation of the interface and switch the MySQL DAO and the DB2 DAO

Therefore its a good practice to have an interface for you DAOs and Services.

Answer 3

My question is Why do we need an INTERFACE when we have a concrete class and why can't we use it directly.

It's simple abstraction. Suppose you are using Oracle Database as your database. So the concrete class will have logic to access(CRUD ops) the Oracle DB. Tomorrow if your license expires and you no longer want to use Oracle DB, instead you'll want to use MySQL. Now you'll have to rewrite the concrete class already mentioned and with that you'll have to rewrite the service layer too because by directly using the concrete class and it's methods you have a tight coupling between the service layer and data access layer. One should always design systems with loose coupling in mind.

If you were to use an interface instead of the concrete class, the service layer and data access layer have a contract of how to interact. So the service layer will not be impacted by the changes in the data layer because the contract has not changed and they can interact in the same old fashion.

Answer 4

It is always a good design to separate the Interface from the Implementation. It provides more abstraction and flexibility to your code. The clients of your DAO interface do not need to know how it is implemented, but only the methods it provides.

In the end, interfaces are a good practice for maintainability of your code.

Just to add, in my experience in Unit Tests via mocks, it is a lot easier to create mock objects when the object you're mocking has an interface. So using interfaces, for me, makes it easier to isolate and test your code.

Answer 5

This is more around logical separation of code.

For detailed information about interfaces please read this page from Java:

http://docs.oracle.com/javase/tutorial/java/concepts/interface.html

Answer 6

One good reason is that it makes it easy to write mock implementations for testing your application.

Say you want to test module X that uses the UserService. When you write test code, you'll want it to not use the real UserService, but a special test version of UserService that returns some predefined test data. So, in your test, you pass your own mock implementation of IUserService instead of the real UserService.

Also, it makes it easier to in the future extend the system with a different implementation of IUserService. Maybe you now have a UserService that reads information about users from a database. In the future you might, for example, also want to have a UserService that gets information from LDAP. That would just be another implementation of IUserService. Since the rest of the application uses the UserService only through the interface, it will be easy to swap out one implementation for the other.