Reason for using Interface than implement it later

Question

My quesiton is to just: why people do this:

Interface:

public interface CarDAO {

void addCar(Car car);

List<Car> readAll();

void deleteCar(Long id);

}

than create a class that implements carDAO

    public class CarDAOImpl implements CarDAO {

    private SessionFactory sessionFactory;

    private Session getCurrentSession(){

    return sessionFactory.getCurrentSession();

    }

    public void addCar(Car car) {

all the code to add the car    
    }
    public void deleteCar(Car car) {

all the code to delete the car    
    }

why not just create a carCRUDclass without the interface?

One underrated/oft-ignored feature of Interfaces is that, using them *minimizes reliance on exposed subtype relationships* :) — user2864740, Feb 19 '14 at 17:51

score 3 · Answer 1 · answered Feb 19 '14 at 17:50

Interfaces are most valuable in any language because let you separate interface and implementation completely.

Clients deal with the interface; they don't need to know how something is done.

If you decide to swap in a new implementation later, you can do it without affecting clients.

If you do it with your CRUD class you'll have to rewrite every client that uses it.

Look at the java.sql package - it's all interfaces. JDBC driver vendors supply the implementations, so you don't have to worry about vendors. If you swap databases, you simply put a new JAR in your CLASSPATH. All your code that deals with interfaces still works.

Another great example is in the java.util Collections API. You should prefer the interface java.util.List. Whether or not it's ArrayList or LinkedList behind it won't matter to your clients.

This is the basis for dynamic proxy generation, aspect oriented programming, mocking, all sorts of stuff. You can't consider yourself an object-oriented developer unless you understand how to use interfaces well.

but if i have to add for example a new CRUD, i my example, it dont have a "update()" function, if i have to add this feature i have to it in DAO, and daoimplements, double work, and the client will never now this, its in the "back-end" of the application, why should i hide something that is never in the screen for the client, i dont get the point =/ and if i have to add a new feature, i still have to edit the dao and daoimplements in every clients, its not "auto" — user3284660, Feb 19 '14 at 18:06
"Double work"? The example I gave certainly is auto if the interface is stable. It's not double work, because you still have to change it in every client whether you use the interface or not; the interface just means that you add it one more time to the interface. By all means, don't follow the example of the designers of Java itself and do it your way. You're much smarter than they are. — duffymo, Feb 19 '14 at 18:33

score 0 · Answer 2 · answered Feb 19 '14 at 17:49

Because there may be more than one implementation of CarDAO. One will be picked either at compile time or at run time.

Another reason is to abstract the callers from knowing which implementation is being used. Could be a JPA implementation today, could be a MongoDB implementation tomorrow. Clients should not need to change.

score 0 · Answer 3 · answered Feb 19 '14 at 17:51

Lets say you have an ArrayList and you have a few classes that implement CarDAO. These Classes could be Car1, Car2, and Car3. Since they all implement the class CarDAO they can all be added to the ArrayList previously stated. Also you can iterate through all of the CarDAO implementations and call the methods in common since they all inherit the methods of CarDAO

score 0 · Answer 4 · answered Feb 19 '14 at 17:52

The term "contract" is used in connection with interfaces. The interface defines the "contract" between the application and the implementation.

This is to ensure that at a minimum you have to provide methods with the same signatures as the interface. The code won't compile otherwise.

score 0 · Answer 5 · answered Feb 19 '14 at 18:12

Interfaces define behavior and objects that implement interfaces provide object specific implementation for each behavior.
In your example, CarDAO is interface and let's say it has two implementors
1. HibernateCarDAO
2. MybatisCarDAO

Now, each of these implementation will provide addCar(Car c) and deleteCar() functionality, allowing user of CarDAO to pick appropriate implementation.

I'd suggest looking at some posts that talk about naming conventions for implementations. Names like CarDAOImpl really make the concept confusing. Cleaner names will make the concept stand out.

Reason for using Interface than implement it later

5 Answers5