在界面中使用界面作爲參數和返回類型的缺點

這是一個與語言無關的問題。從概念上講，編寫接口（合同）代替特定的實現是很好的。我對這種做法的理解沒有任何問題。但是，當我真的在這種實踐中編寫代碼時，我的類的用戶不時需要爲特定功能的特定需求強制轉換接口，這些特定功能由實現該接口的特定類提供。在界面中使用界面作爲參數和返回類型的缺點

我知道必須有錯誤，無論是在我的一邊還是在用戶的一邊，因爲接口應該公開所有可能有必要的方法/屬性（在c＃的情況下）。

代碼庫龐大，用戶是客戶端。在任何一方進行更改都不會特別容易。

這讓我想知道使用接口作爲參數和返回類型的一些缺點。人們可以請列舉這種做法的缺點嗎？如果您知道如何解決此問題，請包括任何解決方案。

非常感謝您的啓發。

編輯：更具體一些：假設我們有一個名爲DbInfoExtractor的類。它有一個公共的方法的GetInfo，如下所示：

public IInformation GetInfo(IInfoParam);

其中IInformation是由特定的類似VideoInfo，AudioInfo，TextInfo等實現的接口; IInfoParam是由像VidoeInfoParam，AudioInfoParam，TextInfoParam等特定類實現的接口;顯然，根據傳遞給方法GetInfo的特定對象，DbInfoExtractor需要採取不同的操作，因爲可以合理地假設對於不同類型的信息，提取器會考慮不同的方面集（例如{大小，標題，日期}，文本信息的{標題，作者}等作爲搜索關鍵字並以不同方式搜索相關信息。

在這裏，我看到兩個選項： 1，使用if ... else ...根據GetInfo方法接收的參數類型決定實際採取的操作。這當然是不好的，因爲避免這種情況是我們使用多態性的原因之一。

2，我們應該調用IInfoParam.TakeAction（），並且IInfoParam的每個具體實現都有自己的TakeAction（）方法來實際搜索並從數據庫中查找相應的信息。這個選項似乎更好，但仍然很糟糕，因爲它不應該是採取行動搜索和查找信息的參數;它應該是DbInfoExtractor的責任。

那麼如何將TakeAction委託給DbInfoExtractor？（其實，我寫了一些代碼來做到這一點，但它既不規範也不優雅，基本上我做嵌套類在DbInfoExtractor參數類，以便他們可以調用DbInfoExtractor的TakeAction的各種版本。）

請賜教！謝謝。謝謝。

來源

2013-04-03 h9uest

爲什麼不

public IVideoInformation GetVideoInformation(VideoQuery); 
public IAudioInformation GetAudioInformation(AudioQuery); 
// etc.

它看起來並不像有需要的多態性在這裏。

查詢類型爲Query Objects，如果您需要的話。他們可能不需要成爲接口;他們對數據庫一無所知。一個簡單的參數列表（可能只是ID）可能就足夠了。

問題是客戶有什麼問題，他們想要什麼？這是你的界面。

開關語句和鑄造是一種氣味，通常意味着你違反了Liskov substitution principle。

來源

2013-04-03 17:09:04 TrueWill

在界面中使用界面作爲參數和返回類型的缺點

回答

相關問題