Java – Why use interface in Dao design pattern or other design patterns

design-patternshibernatejavaspring

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.

Best Answer

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.

Related Solutions

On design patterns: When should I use the singleton

On my quest for the truth I discovered that there are actually very few "acceptable" reasons to use a Singleton.

One reason that tends to come up over and over again on the internets is that of a "logging" class (which you mentioned). In this case, a Singleton can be used instead of a single instance of a class because a logging class usually needs to be used over and over again ad nauseam by every class in a project. If every class uses this logging class, dependency injection becomes cumbersome.

Logging is a specific example of an "acceptable" Singleton because it doesn't affect the execution of your code. Disable logging, code execution remains the same. Enable it, same same. Misko puts it in the following way in Root Cause of Singletons, "The information here flows one way: From your application into the logger. Even though loggers are global state, since no information flows from loggers into your application, loggers are acceptable."

I'm sure there are other valid reasons as well. Alex Miller, in "Patterns I Hate", talks of service locators and client side UI's also being possibly "acceptable" choices.

Java – a serialVersionUID and why should I use it

The docs for java.io.Serializable are probably about as good an explanation as you'll get:

The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException. A serializable class can declare its own serialVersionUID explicitly by declaring a field named serialVersionUID that must be static, final, and of type long:

ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;

If a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in the Java(TM) Object Serialization Specification. However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class — serialVersionUID fields are not useful as inherited members.

Best Answer

Related Solutions

On design patterns: When should I use the singleton

Java – a serialVersionUID and why should I use it

Related Topic