是否實現多個接口違反單一職責原則

Question

從Wikipedia：

「單一職責原則，即每類應該有一個責任的國家，這責任應該由類完全封裝。」

這是否意味着實現多個接口違反了這個原則？

Answer 1

我不會說自己。一個班級可以承擔一個責任，但是在這個過程中要做很多事情，並且爲了履行其責任所需要做的每件事情都要實現一個界面。

此外，Java中的接口可用於說明該類所具有的屬性（例如，Comparable和Serializable），但沒有真正說出該類的責任。

但是，如果一個類實現了多個接口，其中每個接口對應於一個責任，那麼然後是這將違反該原則。

Answer 2

「單一責任」取決於抽象層次。例如，考慮到系統級別的複雜系統可能有一個責任。例如，電視系統的責任是顯示視頻圖像。在下一級，該系統由子系統，監視器，動力裝置等組成。在這個級別，每個單元都有自己的責任。

以同樣的方式，一個級別的一個級別可能被認爲具有單一責任。但是，在較低層次上，它可能有其他組成模塊（類，接口等）執行其部分工作。例如，學生班的職責是代表學生抽象。然而，它可能有另一個代表學生地址的單元（一個班級）。

這樣，使用多個接口本身並不違反面向對象的原則。

Answer 3

也許，但不一定。

接口不是一個責任。 There's a very powerful mode of architecture，其將界面視爲定義該對象可以在應用程序中播放的角色。

想一下這是什麼意思。你可以有一個Person類的各種接口（讓我們使用.NET約定命名）

class Person : IAmAStudent, IDrawSocialSecurity, IAmACitizen { 
    public SocialSecurityNumber getSocialSecurityNumber() { 
     return this.ssn; 
    } 
    private SocialSecurityNumber ssn; 
    public Person(SocialSecurityNumber ssn) { this.ssn = ssn; } 
} 

現在顯然這不能違反SRP。顯然只有一個變化原因 - 如果人與社會安全號碼之間的關係發生變化。然而，該對象實現了許多接口，並在應用程序中扮演了幾個角色

現在，如果您實施的多個接口公開不同的功能，您可能會違反SRP，但這也可能是一個判斷呼叫。單一責任原則對於實現鬆耦合來說是一個很好的經驗法則，但這不是鎮上唯一的理想。還有高凝聚力其中規定相關的代碼應該共同生活。這兩者基本上存在矛盾（儘管通常有很多方法可以實現良好的平衡）。所以你可能會合理地選擇一個在另一個的方向，並有意識地決定違反SRP。

最終，SRP和所有SOLID規則更多的是確保您按照特定的思路思考，而不是每次盲目追隨他們。