title: Why always have single implementation interfaces in service and dao layers?
body: <p>I've worked/seen a few spring-hibernate web application projects having as many interfaces as there are actual service and dao classes.</p>
  
  <p>I always thought that these two as the main reasons for having these single implementation interfaces:</p>
  
  <ol>
  <li><p>Spring can wire actual implementation as dependencies in a given class (loose coupling)   </p>
  
  <pre><code>public class Person { 
      @Autowired 
      private Address address;
  
      @Autowired 
      private AccountDetail accountDetail;
  
      public Person(Address address, AccountDetail accountDetail) 
      { // constructor
  </code></pre></li>
  <li><p>While unit testing, I can create mock classes and test a class in isolation.</p>
  
  <pre><code>Address mockedAddress = mock(Address);
  AccountDetail mockedAccountDetail = mock(AccountDetail);
  Person underTestPerson = new Person(mockedAddress, mockedAccountDetail); 
  // unit test follows
  </code></pre></li>
  </ol>
  
  <p>But, of late, I realized that:</p>
  
  <p>Spring can wire concrete implementation classes as dependencies:</p>
  
  <pre><code>public class Person { 
  
  @Autowired 
  private AddressImpl address;
  
  @Autowired 
  private AccountDetailImpl accountDetail;
  
  public Person(AddressImpl address, AccountDetailImpl accountDetail) { 
  // constructor
  </code></pre>
  
  <p>Mock frameworks like EasyMock can mock concrete classes as well</p>
  
  <pre><code>AddressImpl mockedAddress = mock(AddressImpl);
  AccountDetailImpl mockedAccountDetail = mock(AccountDetailImpl);
  Person underTestPerson = new Person(mockedAddress, mockedAccountDetail); 
  // unit test follows
  </code></pre>
  
  <p>Also, as per <a href="https://stackoverflow.com/questions/90851/is-it-just-me-or-are-interfaces-overused">this</a> discussion, I think the summary is that within a single app, interfaces are mostly overused probably out of convention or habit. They generally make best sense in cases where we are interfacing with another application for example slf4j used by many apps around the world. Within a single app, a class is almost as much an abstraction as an interface is.</p>
  
  <p>So, my question is why do we still need Interfaces and then have single implementations like *ServiceImpl and *DaoImpl classes and unnecessarily increase our code base size. Is there some issue in mocking concrete classes that I’m not aware of.</p>
  
  <p>Whenever I've discussed this with my team-mates, only answer I get is that implementing service and dao classes based on interfaces is THE DESIGN everybody follows - they mention about spring best practices, OOP, DDD etc. But I still don't get a pragmatic reason behind having so many interfaces within an isolated application.</p>