返回類型的具體類型或接口？

Question

今天我來到了對象編程風格，具體類型或接口的基本悖論。

最好的方法的返回類型是什麼：具體類型或接口？

在大多數情況下，我傾向於使用具體類型作爲方法的返回類型。因爲我相信一個具體的類型對於進一步的使用更加靈活，並且暴露更多的功能。

這個陰暗面：耦合。 天使之一：一個具體的類型包含你最初將要返回的接口和額外的功能。

你的拇指規則是什麼？

這是否有任何編程原則？

---

BONUS：這是我的意思拇指ReadOnlyCollection or IEnumerable for exposing member collections?

Answer 1

我的經驗法則：

1）首先，我有方法返回的接口類型，因爲它總是容易在以後如果需要更改爲具體類型。更難以回到其他方式。

2）即使該方法被聲明爲返回具體類型，我會編寫調用方以儘可能使用接口類型：
InterfaceType i = xyz.methodThatReturnsConcreteType();。

3）無論是我自己調用代碼有差別太大（內部VS公共API）：

• 如果我自己調用問題（該方法即內部API代碼），那麼更願意我將返回具體類型。
• 如果我不控制調用此方法的代碼（例如公共API），則更有可能返回接口類型。 返回具體類型是一種承諾，一般來說，我承諾的越少，越容易。

其他注意事項：

• 測試可能與接口更容易，因爲我可以使用實現該接口的模擬對象。
• 有一個外部的機會，我希望回到一個proxy object（我現在真的很深遠的藉口）

綜上所述，

• 我通常返回接口類型因爲我認爲鬆耦合的好處超過了充分利用混凝土類型的便利性。
• 但是，我不反對切換到返回具體類型在個案的基礎上，只要方便超過鬆耦合的好處。

Answer 2

規則，在返回類型的例子，是儘可能具體，在參數類型儘可能非特異性。也更喜歡接口，因爲如果需要的話，稍後可能會更改您的實現，而無需更改API的客戶端。

Answer 3

有趣的問題。我相信你必須問自己如何使用回報數據。使用古老的汽車來比喻，如果你有

public AccelerationResponse PressAccelerator(float force) {} 

有機會，你會想返回一個接口，而不是一類。您可能會根據特定條件對此響應進行不同解釋。

如果確保您的回報只能按照具體實施所期望的方式使用，那麼使用該類是有意義的。我不確定任何廣泛接受的原則，但我的經驗法則是，如果返回類型可以在不同的實現中重用，那麼接口更有意義。