您是否爲域模型中的每個公共類定義了一個接口？優點和缺點？

Question

您是否爲您的域模型中的每個公共類實現了一個接口？優點和缺點？

更新：如果存儲庫接口和域模型類是在單獨的程序集中定義的，如果我們沒有爲每個域類定義接口，那麼是否存在循環依賴關係。

Answer 1

No.

缺點：

1. 噪聲代碼。
2. 更多要寫。
3. YAGNI。

Answer 2

不可以。只有當你需要的接口。如果您嘗試並儘早考慮，您的代碼將變得複雜且不可維護。有一段時間，程序員會拋棄接口，因爲太難以通過接口來弄清楚需要什麼。爲了做而做的任何事情都會導致災難。

Answer 3

從我的角度來看，這是過分的。只是我的2美分...

Answer 4

不，我不這樣做... 爲什麼你會這樣做，如果現在沒有必要呢？

如果它應該在將來出現，應該是必要的（那些'應該'表明它是一個YAGNI），您可以執行'提取接口' - 重構。
（現代的IDE使它很容易這樣做）。

Answer 5

我可能會在我的下一個Asp.Net項目中做到這一點。

我的理由是我們在當前的項目中需要某處存儲一些與UI相關的額外狀態。如果我們使用了領域模型類的接口，那麼我們可以在用戶控制代碼中使用實體類的子類，並用我們自己的具有該額外狀態的類進行替換。

我知道，它似乎有點骯髒。我很樂意在Java的Seam框架中使用對話機制。

Answer 6

您應該爲圖層之間的依賴關係定義接口，而不是爲每個類定義接口。因此，您的服務層應該依賴於存儲庫接口，並且您的表示層應該依賴於服務接口。過去，沒有太多硬性和快速的規則，否則就在有意義的地方使用它們。

常識是任何優秀設計的重要組成部分。

Answer 7

這取決於項目的類型。如果您正在編寫將被大量重用的API（例如Sharepoint API包裝器），我會更傾向於這樣做。

對於其他不會重複使用的項目，默認情況下，我不會強調每個公共類都有一個接口。我會專注於使用精心設計的界面來連接圖層。

Answer 8

從永恆的你可能會考慮把界面上你的域對象的角度來看：

在你會想你的對象是不可改變的代碼中的大多數地方，這樣就可以保證他們不會被改變 - 在這種情況下，您將使用某種返回接口的數據訪問對象，以確保您的域對象不能被更改。

如果你正在寫某種當用戶將最終編輯域對象的管理頁面中，您將需要公開制定者 - 你的數據訪問對象需要返回「MutableDomainObject」 instanaces（一個類或一個子接口）。

話雖如此，我同意YAGNI的上述哲學 - 如果您目前不需要保證不變性，那麼目前可能不值得投資。在以後的日子裏分析接口應該不會太困難。

Answer 9

可以通過爲特定情況下類正在播放的角色命名一個接口來使代碼更具表現力。一個班級可能扮演不止一個角色。例如，當一個人與貓交互時，貓可能具有寵物接口，而當鼠標與貓交互時，貓可能具有捕食者界面。

你可能會發現Mock Roles, not Objects一個相關的和有趣的閱讀。