接口隔離原理和便利/輔助方法

Question

接口隔離原理如何應用於便利/輔助方法？例如：

我想創建一個表示業務夥伴的接口。最低限度，我需要將是一個setter和將設置或獲取合作伙伴的完整列表getter方法：

Interface Partners { 
    method getList(); 
    method setList(); 
} 

我也希望有一個contains（）方法，如果告訴我某個人被列入合作伙伴名單。我認爲這是一個助手或便利方法，因爲它只是調用getPartners（），然後檢查給定的人是否在該列表中。

我對接口隔離原理的理解是，我應該將我的contains（）方法分離到一個單獨的接口中，因爲有人可能想實現我的Partners接口而不提供此不必要的輔助方法的實現。在我的例子中，它並不是什麼大不了的事，但是輔助方法列表可以很快增長（addPartner，addPartnerByID，addPartnerByUserid等），所以這是一個實際問題。

我的問題是，我發現選擇一個接口的名字非常困難，因爲我的contains（）方法聽起來並不麻煩，我認爲任何時候你在命名時都有這麼多麻煩，它是一個紅旗表明你的設計有問題。擁有一個名爲PartnersSupportingSetInclusionChecks的接口似乎不太合適，但看起來只有一個名爲PartnerHelperMethods的接口似乎也不錯。

如何將接口隔離原理應用於這些方法？

Answer 1

因爲有人可能想實現我的合作伙伴接口，而通過各種手段爲這個不必要的輔助方法，

重點煤礦

請提供一個實現有方法，如果你認爲它是在您的API中很重要。尤其是如果你所有的客戶端代碼都使用一個。

接口隔離原則是保持界面之外完全不相關的方法。它看起來像你試圖實現一個Repository應該有一個get，包含等方法來查看存儲庫中的元素和檢索它們的方法。

如果您有其他類型的方法與獲取或設置合作伙伴無關，則應該使用ISP爲此創建不同的接口。

但是，如果您認爲您的客戶端將此存儲庫視爲只讀並且不應允許修改它，您可能需要考慮將您的獲取/包含方法從設置/添加方法中分離出來，但是您不必。