Why do we use the interface in the MVC spring template?

Question

I am new to spring MVC, I uploaded a small spring MVC project. The project runs fine, but this interface and project classes are used. as

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); } }
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); } } 

I doubt that if we use EmployeeServiceImpl , what is needed to implement EmployeeService ? the same is in EmployeeDao and EmployeeDaoImpl .

Answer 1

Interfaces are always good practice for decoupling, but also when talking about Spring, there are a few functions that you can use with interfaces, not specific classes.

The 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, such as post-processing and the like, but I think you will have an interesting read on Spring AOP.

Answer 2

Weather spring mvc or not, you always need to code the interface. The interface gives me better readability when I just want to see what the class does and not worry about how it does it, like an API that is open to the outside world.

Another advantage can be multiple "how to do" implementations, and spring helps you easily switch between multiple implementations. E.g. you may have another implementation of EmployeeService, e.g. FullTimeEmployeeServiceImpl, RemoteEmployeeServiceImpl.

Now, if you have a client class that uses EmployeeService:

 class EmployeeManager{ private EmployeeService service; } 

you can enter any of the 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 abbreviation for OO design relate to this:

• The principle of Liskov substitution is that you must replace any subtype of T without affecting the outcome of the problem. For example, if you call a method that returns List<> , and the base implementation switches from returning ArrayList<> to LinkedList<> , your program should still work in the same way. Basically, you should design your classes so that client dependencies can be replaced with subclasses without the client being aware of the change. The following is a short fragment of a wiki page:

Substitution is a principle in object-oriented programming. This states that in a computer program, if S is a subtype of T, then objects of type T can be replaced by objects of type S (i.e. objects of type S can replace objects of type T) without changing any of the desired properties of this program (correctness, task done, etc.)

2. Dependency Inversion Principle - The basic idea is that you isolate the class abroad based on the abstractions on which it depends. Thus, if any part that sits behind these abstractions changes, the class will not be affected.

In object-oriented programming, the dependency inversion principle refers to a certain form of decoupling software modules. when following this principle, the traditional dependency relationships are installed from high-level, setting the policy of the modules to low-level, the dependency modules are inverted (i.e. vice versa), which makes high-level modules independent of the implementation of the low-level module Details. State principle

  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

He has few. do with Spring or MVC. It is good practice to develop with interfaces, so the implementation can be easily changed. It provides a loose connection, and if you use Spring, you can change the implementation. When required.

It also helps during testing with Junit. You can easily mock up your dao.

Answer 5

It is recommended that you write code against interfaces instead of specific implementations.

Thus, the client code does not know specific implementations, but knows only the contract.

As for Spring, you usually need to use interfaces, since Spring often needs to create Java proxies, and this can only be done for classes that implement interfaces.