Why we are using interface in spring MVC pattern?

Question

I am new to spring MVC , I have downloaded a small spring MVC project . The project is executing fine but it this project interfaces and classes are being used . like

public interface EmployeeService {

    public void addEmployee(Employee employee);

    public List listEmployeess();

    public Employee getEmployee(int empid);

    public void deleteEmployee(Employee employee);
}

And

public class EmployeeServiceImpl implements EmployeeService {

    @Autowired
    private EmployeeDao employeeDao;

    @Transactional(propagation = Propagation.REQUIRED, readOnly = false)
    public void addEmployee(Employee employee) {
        employeeDao.addEmployee(employee);
    }

    public List listEmployeess() {
        return employeeDao.listEmployeess();
    }

    public Employee getEmployee(int empid) {
        return employeeDao.getEmployee(empid);
    }

    public void deleteEmployee(Employee employee) {
        employeeDao.deleteEmployee(employee);
    }

}

My doubt is if we are using EmployeeServiceImpl what is the need of implementing EmployeeService ? same thing is there in EmployeeDao and EmployeeDaoImpl.

Answer 1

Interfaces are always a good practice for decoupling, but also, when speaking about Spring, there are several features you can use having interfaces rather than concrete classes.

A big advantage is proxying - Spring AOP.

You can find more information here: http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/aop.html

There are other advantages, like post processing and things like that, but I think you will have an interesting reading on Spring AOP.

Answer 2

Weather spring mvc or not, one should always code to interface. Interface gives me better readability when i just want to see what the class does instead of worrying about how it does it, kind of API exposed to outer world.

Another benefit is there could be multiple implementations of 'how to do' it and spring helps to switch easily between multiple implementations. For e.g. you could have one more implementation of EmployeeService say FullTimeEmployeeServiceImpl, RemoteEmployeeServiceImpl.

Now if you have client class which uses EmployeeService:

class EmployeeManager{
    private EmployeeService service;
}

you can inject any of bean here

<bean id="employeeManager" class="com.abc.EmployeeManager">
  <property name="service" ref="fullTimeEmployee | remoteEmployee" >
</bean>

<bean id="fullTimeEmployee" class="com.abc.FullTimeEmployeeServiceImpl" />
<bean id="remoteEmployee" class="com.abc.RemoteEmployeeServiceImpl" />

Answer 3

A few principles that are part of the SOLID acronym for OO design apply to this:

1. Liskov substitution principle - you should be able substitute any subtype of T without affecting the outcome of the problem. E.g., if you call a method that returns a List<>, and the underlying implementation switches from returning an ArrayList<> to a LinkedList<>, your program should still perform in the same manner. Basically, you should design your classes so that client dependencies can be substituted with subclasses without the client knowing about the change. Here is a short snippet from the wiki page:

Substitutability is a principle in object-oriented programming. It states that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may substitute objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.)

2. Dependency inversion principle - The main idea is that you isolate the class behind a boundary based upon the abstractions it depends on. That way if any of the details that sit behind those abstractions change, the class will be unaffected.

In object-oriented programming, the dependency inversion principle refers to a specific form of decoupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed), thus rendering high-level modules independent of the low-level module implementation details. The principle states

    A. High-level modules should not depend on low-level modules. 
       Both should depend on abstractions.
    B. Abstractions should not depend on details. 
       Details should depend on abstractions.

Answer 4

It don't have much .to do with Spring or MVC.It is good practice to design with interfaces, so that implementation can be changes easily. It provides loose coupling and if you are using spring you can siimply change implementation. Whenver needed.

Also , it helps during testing with Junit. You can easily mockup your dao.

Answer 5

It is recommended to write code against interfaces instead specific implementations.

This way, the client code doesn't know the specific implementations but only knows the contract.

Regarding Spring, you generally have to use interfaces since Spring often needs to create Java proxies and this can be done only for classes that implement interfaces.