java的打字系统: prefer interface types to class types as method parameters/return values

Question

我只是努力了解接口(interface)的强大功能以及如何充分利用它们。

到目前为止，我了解接口(interface):使我们能够拥有另一层抽象，分离什么(由接口(interface)定义)和如何(任何有效的实现)。

如果只有一个实现，我只想 build 一座房子(以一种特定的方式)并在这里说，它完成了而不是带着一个建筑计划(界面)来要求你，其他开发人员按照我的期望 build 它.

到目前为止，还不错。

仍然让我感到困惑的是，在涉及方法参数和返回值时，为什么偏爱接口(interface)类型而不是类类型。为什么会这样？有什么好处(类方法的缺点)？

最让我感兴趣的是这实际上是如何转化为代码的。

假设我们有一种伪数学接口(interface)

public interface pseudoMathInterface {

double getValue(); 

double getSquareRoot(); 

List<Double> getFirstHundredPrimes(); 

}

//...

public class mathImp implements pseudoMathInterface { }
//.. actual implementation 

所以对于 getPrimes() 方法，我会将其绑定(bind)到 List，这意味着 List 接口(interface)的任何具体实现，而不是 ArrayList 等具体实现!？

就方法参数而言，我是否会再次扩大我的机会，同时确保我可以使用该类型做任何我想做的事情，因为它是该类型最终实现的接口(interface)契约的一部分。!？

Answer 1

假设您是 Maven 依赖项的创建者，这是一个具有众所周知的、规范明确的 API 的 JAR。

1. 如果您的方法请求 ArrayList<Thing> ，把它当作一个事物的集合，但我所得到的只是一个HashSet<Thing> ，你的方法会扭曲我的 ARM ，将所有内容复制到 ArrayList 中没有任何好处；

2. 如果您的方法声明返回 ArrayList<Thing> ，它(在语义上)仅包含一个事物集合，并且其中元素的索引没有任何意义，那么您将永远约束自己返回一个实际的 ArrayList。 ，即使例如该项目的 future 进程表明，迫切需要专门针对优化此方法的典型用例而定制的自定义集合实现，以改善关键性能瓶颈。

   您被迫进行 API 重大更改，同样对您的客户没有任何好处，只是为了解决内部问题。与此同时，有人在编写假定 ArrayList 的代码。 ，例如按索引遍历它(这样做有极小的性能提升，但早期的优化器对他们来说已经足够了)。

我建议您明智地将上述两个陈述归纳为一般原则，以捕捉您的问题的“原因”。