为何使用接口

Question

我看到了界面的好处，能够通过合同添加新的实现。

我没有看到以下问题： 想象一下，你有方法＆＃34; startTransaction＆＃34;的接口数据库。 一切都很好，你在MySQL，PostgreSQL中实现它。但明天你转移到mongodb - 然后你没有交易支持。

你做什么的？ 1）空方法 - 糟糕，因为你认为你有交易，但你没有 2）创建你自己的 - 那么你应该有一些与常规＆＃34; startTransaction＆＃34;不同的参数。方法

最重要的是，有时简单的界面是行不通的。 示例：您需要针对不同实现的其他参数。

Answer 1

如果您在界面上公开了事务的概念，那么必须在功能上支持事务，无论如何，因为接口的用户在逻辑上依赖于它。即，如果调用者可以启动事务，那么他们也希望能够回滚多个查询的事务。由于Mongo本身没有任何回滚交易的概念，因此有两种可能性之一：

1. 您可以实现在代码中回滚查询的可能性，模拟数据库的事务功能，而这些数据库本身并不支持它。 （在Mongo中是否可靠地实现这一点是一个值得商榷的话题。）
2. 您的界面正在以错误的抽象级别工作。如果您的界面是有前途的功能，实现无法提供，那么接口或实现都是不现实的。

在实践中，Mongo和SQL数据库是如此不同的野兽，如果不改变业务逻辑的大部分内容，你就不会做出这种改变。或者您仅使用极小的公分母界面指定您的界面，绝大多数情况下不会在抽象界面上公开特定于技术的概念。

Answer 2

您大多是正确的，接口可能非常有用，但在（快速）更改代码时也存在问题，最好的做法是保持接口尽可能小。

当某些东西可以处理某个事务时，只创建一个用于处理事务的接口。将它们分成尽可能小的逻辑部分，这样，当新类出现时，您可以为它们分配可以确定其方法的特定接口。

对于多参数问题，这确实可能有问题，看看你是否可以确定这个特定值是否可以移动到构造函数，或者表明你正在做的动作确实与不执行的动作有很大不同需要这个参数。

我希望这有帮助，祝你好运

Answer 3

您是正确的接口用于通过合同添加新的实现，但这些实现必须具有一些相似性。 我们来举个例子： 你不能使用人类界面实现狗，因为狗是一个活生物体。 你在这里尝试做同样的事情。你正在尝试使用sql db实现实现非sql db。