问题描述
我曾经/看过一些Spring-hibernate的Web应用程序项目，其实际服务和dao类都有很多接口。
I've worked/seen a few spring-hibernate web application projects having as many interfaces as there are actual service and dao classes.
我一直以为这些两个作为具有这些单一实现接口的主要原因：
I always thought that these two as the main reasons for having these single implementation interfaces:
-
Spring可以将实际实现作为给定类中的依赖关系联系）
Spring can wire actual implementation as dependencies in a given class (loose coupling)
public class Person {
@Autowired
private Address address;
@Autowired
private AccountDetail accountDetail;
public Person(Address address, AccountDetail accountDetail)
{ // constructor
单元测试时，我可以创建模拟类并隔离测试一个类。
While unit testing, I can create mock classes and test a class in isolation.
Address mockedAddress = mock(Address);
AccountDetail mockedAccountDetail = mock(AccountDetail);
Person underTestPerson = new Person(mockedAddress, mockedAccountDetail);
// unit test follows
但是，最近我意识到：
Spring可以将具体的实现类作为依赖关系：
Spring can wire concrete implementation classes as dependencies:
public class Person {
@Autowired
private AddressImpl address;
@Autowired
private AccountDetailImpl accountDetail;
public Person(AddressImpl address, AccountDetailImpl accountDetail) {
// constructor
像EasyMock这样的模拟框架也可以模拟具体的类。
Mock frameworks like EasyMock can mock concrete classes as well
AddressImpl mockedAddress = mock(AddressImpl);
AccountDetailImpl mockedAccountDetail = mock(AccountDetailImpl);
Person underTestPerson = new Person(mockedAddress, mockedAccountDetail);
// unit test follows
另外，根据讨论，我认为总结是在单个应用程序中，界面大多被过度使用的惯例或习惯。在我们与另一个应用程序（例如世界各地许多应用程序使用的slf4j）进行接口的情况下，它们通常是最有意义的。在单个应用程序中，类与界面几乎是一样的抽象。
Also, as per this 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.
所以，我的问题是为什么我们仍然需要接口，然后有单个实现，如* ServiceImpl和* DaoImpl类，不必要地增加我们的代码库大小。有没有一些嘲弄我不知道的具体课程的问题。
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.
每当我和我的队友讨论这个问题时，只有回答我才能实现基于接口的服务和Dao类是设计每个人都遵循 - 他们提到有关春季最佳实践，OOP，DDD等。但是我仍然没有在孤立的应用程序中拥有这么多接口的实际原因。
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.
推荐答案
接口有更多的优点 - 在代理中。如果你的类实现一个接口，默认情况下，AOP将使用JDK动态代理。如果直接使用这些实现方式，那么将被迫使用CGIIB代理，方法是使proxy-target-class = true。这些需要与JDK代理不同的字节代码操作。
There are more advantages to interfaces - As in proxying . If your class implements an interface , JDK dynamic proxies will be used by default for AOP . If you use the implementations directly, you'll be forced to use CGLIB proxies by making proxy-target-class=true . These require byte code manipulation unlike JDK proxies .
阅读了解更多信息。
阅读另一个讨论获取更多信息。
Read another discussion at what reasons are there to use interfaces (J2EE or Spring and JPA) for more info .
这篇关于为什么在服务和dao层中总是有单一的实现接口？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！