今天我遇到了对象编程风格、具体类型或接口的一个基本悖论。
方法的返回类型有什么更好的选择：具体类型还是接口？
在大多数情况下，我倾向于使用具体类型作为方法的返回类型。因为我相信具体类型更灵活，可以进一步使用并提供更多功能。
这方面的阴暗面：耦合。天使般的：一个具体的类型本身包含你最初将要返回的接口，以及额外的功能。
你的拇指法则是什么？
这有什么编程原则吗？
问问题
2405 次
3 回答
8
经验法则，在返回类型中尽可能具体，在参数类型中尽可能不具体。也更喜欢接口，因为如果需要，您可以稍后交换您的实现，而无需更改 API 的客户端。
于 2010-04-21T00:08:15.637 回答
8
我的经验法则：
1）最初，我让方法返回接口类型，因为如果需要，以后总是很容易将其更改为具体类型。更难回到另一条路。
2）即使方法被声明为返回具体类型，我也会尽可能对调用者进行编码以使用接口类型：
InterfaceType i = xyz.methodThatReturnsConcreteType();.
3) 我是否拥有调用代码也会产生影响（内部 API 与公共 API）：
- 如果我拥有调用相关方法的代码（即内部 API），那么我越愿意返回具体类型。
- 如果我不控制调用此方法的代码（例如公共 API），我更有可能返回接口类型。返回具体类型是一种承诺，一般来说，我承诺的越少，就越容易。
其他注意事项：
- 使用接口进行测试可能更容易，因为我可以使用实现接口的模拟对象。
- 有一个外部机会我想返回一个代理对象（现在我真的在找借口）
总之，
- 我通常返回接口类型，因为我觉得松耦合的好处超过了完全访问具体类型的便利。
- 但是，只要方便超过松散耦合的好处，我不反对根据具体情况切换返回具体类型。
于 2010-04-21T00:59:48.157 回答
1
有趣的问题。相信你要问问自己，返回的数据怎么用。如果你有的话，请使用旧车类比
public AccelerationResponse PressAccelerator(float force) {}
您可能希望返回一个接口而不是一个类。根据某些条件，您可能会以不同的方式解释此响应。
如果您保证您的回报只能以具体实现所期望的方式使用，那么使用该类是有意义的。我不确定是否有任何被广泛接受的原则，但我的经验法则是，如果返回类型可以在不同的实现中重用，那么接口会更有意义。
于 2010-04-21T00:08:54.717 回答