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

Question

我只是努力了解界面的强大功能以及如何充分利用它们。

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

只要有一个实现，我就会 build 一栋房子(以一种特定的方式)并在这里说它已经完成，而不是提出一个建筑计划(界面)并要求你，其他开发人员按照我的预期 build 它.

到目前为止，一切都很好。

仍然让我困惑的是，为什么在方法参数和返回值方面更倾向于接口(interface)类型而不是类类型。为什么会这样？类(class)方法有什么好处(缺点)？

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

假设我们有一种伪 mathInterface

public interface pseudoMathInterface {

double getValue(); 

double getSquareRoot(); 

List<Double> getFirstHundredPrimes(); 

}

//...

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

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

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

Answer 1

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

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

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

   您被迫进行API 重大更改，这同样不会给您的客户带来任何好处，而只是为了解决内部问题。与此同时，人们编写的代码假设 ArrayList ，例如按索引迭代它(这样做会带来极其轻微的性能提升，但对于早期的优化器来说这已经足够了)。

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