Java 为什么在 Dao 设计模式或其他设计模式中使用接口

Why use interface in Dao design pattern or other design patterns

提问by user3541375

Please see below components of a Dao design pattern:

请参阅以下 Dao 设计模式的组件：

Data Access Object Pattern or DAO pattern is used to separate low level data accessing API or operations from high level business services. Following are the participants in Data Access Object Pattern.

数据访问对象模式或 DAO 模式用于将低级数据访问 API 或操作与高级业务服务分开。以下是数据访问对象模式的参与者。

Data Access Object Interface - This interface defines the standard operations to be performed on a model object(s).

数据访问对象接口 - 该接口定义了要在模型对象上执行的标准操作。

Data Access Object concrete class -This class implements above interface. This class is responsible to get data from a datasource which can be database / xml or any other storage mechanism.

数据访问对象具体类 - 此类实现上述接口。该类负责从数据源获取数据，数据源可以是数据库/xml 或任何其他存储机制。

Model Object or Value Object - This object is simple POJO containing get/set methods to store data retrieved using DAO class.

模型对象或值对象 - 此对象是简单的 POJO，包含用于存储使用 DAO 类检索的数据的 get/set 方法。

Why do we need an INTERFACE when we have a concrete class and why can't we use it directly? This might be a naive question but please help me get this thing clear. Not only in DAO design pattern but in other design patterns also use of INTERFACE is bit confusing. I agree this is related to code reusabilty and reduced coupling. But can anyone please explain a bit further.

当我们有一个具体的类时，为什么我们需要一个 INTERFACE ，为什么我们不能直接使用它？这可能是一个幼稚的问题，但请帮助我弄清楚这件事。不仅在 DAO 设计模式中，而且在其他设计模式中也使用 INTERFACE 有点混乱。我同意这与代码可重用性和减少耦合有关。但是任何人都可以进一步解释一下。

采纳答案by Matej ?pilár

Not only in DAO design pattern but in other design patterns also use of INTERFACE is bit confusing.

不仅在 DAO 设计模式中，而且在其他设计模式中也使用 INTERFACE 有点混乱。

Interfacesis one of the best used concepts in Java. Let me explain this with an example: Say you designed a GPS device for car which looks into the map and automatically turns the car to the direction as seen in the map. This GPS device can be used in many cars like benz, fiat, etc. For each car, the mechanism of turning the left or right may differ depending on the implementation of the car system. So,these functionsshould be written by the car manufacturer and hence these methods are put in a interface, which is implemented by the car manufacture as per his car's implementation. The interface includes only a set of function declarationswhich are to be defined by the car manufacturer(In this case). Got it?

接口是 Java 中最常用的概念之一。让我用一个例子来解释这一点：假设你为汽车设计了一个 GPS 设备，它可以查看地图并自动将汽车转向地图上看到的方向。该 GPS 设备可用于奔驰、菲亚特等多种汽车。对于每辆汽车，左转或右转的机制可能因汽车系统的实施而异。所以，这些功能应该由汽车制造商编写，因此这些方法被放在一个接口中，由汽车制造商根据他的汽车实现来实现。该接口仅包括一组将由汽车制造商定义的函数声明（在本例中）。知道了？

To learn more about interfaces and why they are useful, read this article.

要了解有关接口及其有用原因的更多信息，请阅读本文。

My question is: Why do we need an INTERFACE when we have a concrete class and why can't we use it directly.

我的问题是：当我们有一个具体的类时，为什么我们需要一个 INTERFACE ，为什么我们不能直接使用它。

Among many other benefits that were pointed out in answers below, you can create many DAO classes for different data structers (derby db, huge stacks etc.), that implements DAO interface. The benefit is, that every class can be stored in DAO interface variable, its called polymorphism.

在下面的答案中指出的许多其他好处中，您可以为实现 DAO 接口的不同数据结构体（derby db、巨大堆栈等）创建许多 DAO 类。好处是，每个类都可以存储在 DAO 接口变量中，称为多态性。

回答by renz

It is always a good design to separate the Interface from the Implementation. It provides more abstractionand flexibilityto your code. The clients of your DAO interface do not need to know how it is implemented, but only the methods it provides.

将接口与实现分开总是一个好的设计。它为您的代码提供了更多的抽象和灵活性。DAO 接口的客户端不需要知道它是如何实现的，而只需要知道它提供的方法。

In the end, interfaces are a good practice for maintainability of your code.

最后，接口是代码可维护性的良好实践。

Just to add, in my experience in Unit Tests via mocks, it is a lot easier to create mock objects when the object you're mocking has an interface. So using interfaces, for me, makes it easier to isolateand testyour code.

补充一点，根据我通过模拟进行单元测试的经验，当您模拟的对象具有接口时，创建模拟对象要容易得多。因此，对我而言，使用接口可以更轻松地隔离和测试您的代码。

回答by Aeseir

This is more around logical separation of code.

这更多是围绕代码的逻辑分离。

For detailed information about interfaces please read this page from Java:

有关接口的详细信息，请阅读 Java 页面：

http://docs.oracle.com/javase/tutorial/java/concepts/interface.html

http://docs.oracle.com/javase/tutorial/java/concepts/interface.html

回答by Jens Baitinger

Actually its not necessary to have an interface when you have only one implementation. But there are certain situation where it is very practical that you dont have a depencecy to the concrete class:

实际上，当您只有一个实现时，没有必要拥有一个接口。但是在某些情况下，您对具体类没有依赖是非常实用的：

• Testing your service that calls the DAO: You can write a mock DAO that behaves just as you need it in the test (e.g. simulat that there is no DB connection, which is hard to reproduce automatically)

• generate some Layers aoround your DAO. You could use AOP to generate caching or transaction handling around your DAO methods. In this case you have an object that implements the DAOs interface but has nothing to do with the original implementation.

• Switching the DB technology. If you switch from MySQL to DB2 you just need to write another implementation of the interface and switch the MySQL DAO and the DB2 DAO

• 测试调用 DAO 的服务：您可以编写一个模拟 DAO，它的行为与您在测试中需要的一样（例如，模拟没有 DB 连接，这很难自动重现）

• 在你的 DAO 周围生成一些层。您可以使用 AOP 围绕您的 DAO 方法生成缓存或事务处理。在这种情况下，您有一个实现 DAO 接口但与原始实现无关的对象。

• 切换数据库技术。如果您从 MySQL 切换到 DB2，您只需要编写接口的另一个实现并切换 MySQL DAO 和 DB2 DAO

Therefore its a good practice to have an interface for you DAOs and Services.

因此，为您的 DAO 和服务提供一个接口是一个很好的做法。

回答by Kishore

My question is Why do we need an INTERFACE when we have a concrete class and why can't we use it directly.

我的问题是当我们有一个具体的类时为什么我们需要一个 INTERFACE ，为什么我们不能直接使用它。

It's simple abstraction. Suppose you are using Oracle Database as your database. So the concrete class will have logic to access(CRUD ops) the Oracle DB. Tomorrow if your license expires and you no longer want to use Oracle DB, instead you'll want to use MySQL. Now you'll have to rewrite the concrete class already mentioned and with that you'll have to rewrite the service layer too because by directly using the concrete class and it's methods you have a tight coupling between the service layer and data access layer. One should always design systems with loose coupling in mind.

这是简单的抽象。假设您使用 Oracle 数据库作为您的数据库。因此，具体类将具有访问（CRUD ops）Oracle DB 的逻辑。明天，如果您的许可证到期并且您不再想使用 Oracle DB，而是想使用 MySQL。现在您必须重写已经提到的具体类，并且您还必须重写服务层，因为通过直接使用具体类及其方法，您在服务层和数据访问层之间具有紧密耦合。设计系统时应始终牢记松耦合。

If you were to use an interface instead of the concrete class, the service layer and data access layer have a contract of how to interact. So the service layer will not be impacted by the changes in the data layer because the contract has not changed and they can interact in the same old fashion.

如果您要使用接口而不是具体的类，则服务层和数据访问层有一个如何交互的契约。所以服务层不会受到数据层变化的影响，因为合约没有改变，它们可以以同样的旧方式进行交互。

回答by user1686621

One good reason is that it makes it easy to write mock implementations for testing your application.

一个很好的理由是，它可以轻松编写用于测试应用程序的模拟实现。

Say you want to test module X that uses the UserService. When you write test code, you'll want it to not use the real UserService, but a special test version of UserService that returns some predefined test data. So, in your test, you pass your own mock implementation of IUserService instead of the real UserService.

假设您要测试使用 UserService 的模块 X。当您编写测试代码时，您会希望它不使用真正的 UserService，而是使用返回一些预定义测试数据的 UserService 的特殊测试版本。因此，在您的测试中，您传递了您自己的 IUserService 模拟实现，而不是真正的 UserService。

Also, it makes it easier to in the future extend the system with a different implementation of IUserService. Maybe you now have a UserService that reads information about users from a database. In the future you might, for example, also want to have a UserService that gets information from LDAP. That would just be another implementation of IUserService. Since the rest of the application uses the UserService only through the interface, it will be easy to swap out one implementation for the other.

此外，它还可以更轻松地在未来使用 IUserService 的不同实现来扩展系统。也许您现在有一个 UserService 可以从数据库中读取有关用户的信息。例如，将来您可能还希望拥有一个从 LDAP 获取信息的 UserService。那只是 IUserService 的另一个实现。由于应用程序的其余部分仅通过接口使用 UserService，因此很容易将一种实现替换为另一种实现。