CODEWITHSUNDEEP
springdesign-patternsjakarta-ee
Arun
Arun

Reputation: 1177

what reasons are there to use interfaces (Java EE or Spring and JPA)

Most of the J2EE(Spring and JPA) classes are designed with interfaces. Except for inheritance, are there any technical reasons for this? Like dynamic proxy or AOP, I need more technical details about this

ex

public interface UserDAO {
   void delete();
   void update();
   void save();
   List<User> get();
}

public class UserDAOImpl implements UserDAO {
   public void delete(){}
   public void update(){}
   public void save(){}
   public List<User> get(){}
}

Upvotes: 13

Views: 7214

Answers (3)

Aravind A
Aravind A

Reputation: 9697

  1. Interfaces for one are contracts as I see them . For example , a set of software engineers(Implementation classes) may have a specific contract with a company(Interface) . The company may choose to switch between the engineers from time to time based on the project needs . Since they come under the same contract and follow the same rules , switching is easier than bringing in a resource from outside (writing a new class) every time the project needs change . You just have to change the configurations to switch the implementation classes .

  2. Interfaces are clean and is a one point access to the rules which the classes implement .

Links

  1. spring and interfaces
  2. What does it mean to "program to an interface"?
  3. http://www.artima.com/lejava/articles/designprinciples.html

Upvotes: 7

Ralph
Ralph

Reputation: 120791

Because you have mentioned Spring explicite.

Spring AOP can be used in different configurations. The default one uses java dynamic proxies (java.lang.reflect.Proxy). This can be only applied to Interfaces

Spring AOP defaults to using standard J2SE dynamic proxies for AOP proxies. This enables any interface (or set of interfaces) to be proxied.

@see Spring Reference Chapter 7.1.3 AOP Proxies @see Dynamic Proxy Classes

Upvotes: 5

JB Nizet
JB Nizet

Reputation: 691755

There are 3 main reasons, IMO:

First reason: proxies.

If you ask Spring for the bean of type UserDAO, it will in fact return a proxy encapsulating the actual UserDAOImpl instance. This allows it to demarcate transactions, verify security authorization, log accesses, compute statistics, etc. It's possible to do it without an interface, but then byte-code manipulation is needed.

Second reasons: testability.

When unit-testing a business service which uses a UserDAO, you typically inject a mock UserDAO implementation. Once again, this is easier to do when UserDAO is an interface. It's possible with a concrete class, but it has not always been, and it's still easier with an interface

Third reason: decoupling.

By using an interface, you have a place where you define the real contract of the DAO for its clients. Sure, it needs a setDataSource() method in the concrete implementation, but clients don't care about that. All they need is set of data-access methods offered by the DAO. By separating the interface and the concrete implementation, you make sure that the client doesn't rely on implementation details of the DAO.

Upvotes: 31

Related Questions