什麼時候界面分離原則不適用？ SOA？

我正在尋找不應使用接口分離原則（來自SOLID）的方案示例。什麼時候界面分離原則不適用？ SOA？

，我已經看到提到的（但不解釋）中只有一個是在SOA環境中服務的接口的情況下。但爲什麼？是否因爲在這種情況下，界面應該設計得很胖？通過SOA法令？

有沒有其他情況下，ISP不是一個好主意？

在此先感謝。

2011-12-07 mnrtyrpt123

SOLID是一個很好的原則，我的想法是，當你認爲你是過度工程時，你不應該使用它們！例如，我主要將ISP應用於服務層的類，在業務層中，我將更改我的類，因爲這是業務中的變化，我不會創建新的實現（並打破「打開/關閉」原則，但我不在乎，因爲這是業務變化！）。

編輯：我在數據層也適用於ISP，所以我其實我申請ISP主要是針對所有的I/O事務（XML，SQL，電子郵件...）。

如果你申請ISP的每一個地方，你會擁有數百個接口，這可能是一場噩夢調試/初始化。

來源

2011-12-08 08:24:22

-2

如果我沒有超過1個實現，我不使用接口。當時間到了我應用這個原則。關於接口的整個想法是有多個實現。祝你好運。

來源

2011-12-07 17:03:07 mynkow

關於接口的想法是在不知道其實現的情況下用接口說話！接口並不是一個讓你能夠將函數應用於不同實現的工具，當你不想在所有類之間進行依賴關係時，這是一種開發方式。 –

-1接口沒有映射到類的1-1。 imho界面應該解決比一個類更小，更具體的問題。 'IEnumerable '就是一個很好的例子。 – jgauffin

@remi當你100％確定只有一個實現時，爲什麼你想留在界面後面？引入界面和增加額外噪音有什麼好處？ – mynkow

的好時機不適的ISP是當你已經開始與小接口，並隨着時間的推移，你更多地瞭解域和發現，他們中的一些耦合。那些被耦合的可以被重構成更少的接口，因爲你可以從現實世界的用法（Rule Of Three）看到它們屬於一起 - 它們的行爲是相關的;它們用於相同的上下文和場景中。有了這種相關界面的經驗，可以做出明智的決定來將它們摺疊起來。然後你的域名變得更豐富，你是not being DRY too early。

問題與上述建議是，你實際上應用ISP從小開始，然後移動到較大。也許這個問題沒有意義？：p

來源

2016-12-22 14:43:09

什麼時候界面分離原則不適用？ SOA？

回答

相關問題