一個類只負責完成一個職責或者功能。

什麼是單一職責原則：

一個類只負責完成一個職責或者功能。不要設計大而全的類，要設計粒度小、功能單一的類。單一職責原則是為了實現程式碼高內聚、低耦合，提高程式碼的複用性、可讀性、可維護性。

但不同的應用場景、不同階段的需求背景下，對同一個類的職責是否單一的判定，可能都是不一樣的。在某種應用場景或者當下的需求背景下，一個類的設計可能已經滿足單一職責原則了，但如果換個應用場景或著在未來的某個需求背景下，可能就不滿足了，需要繼續拆分成粒度更細的類。

比如這裡有一個關於“使用者資訊”的類是否滿足單一職責原則呢？不同的場景下是容易得出不同的結論的

假設只是為了滿足“使用者資訊”這一個需求，那麼這個類顯然是可以滿足的，但系統中若是還有類似於“電商”等功能，需要對地址資訊多次處理的話，那麼UserInfo中的地址資訊反而顯得過於“臃腫”，這個時候就可以嘗試著將這些地址資訊剝離出來作為一個新的“地址資訊”類會更好。

public class UserInfo {
  private long userId;
  private String username;
  private String email;
  private String telephone;
  private long createTime;
  private long lastLoginTime;
  private String avatarUrl;
  private String provinceOfAddress; // 省
  private String cityOfAddress; // 市
  private String regionOfAddress; // 區 
  private String detailedAddress; // 詳細地址
  // ...省略其他屬性和方法...
}
 

我們可以先寫一個粗粒度的類，滿足業務需求。隨著業務的發展，如果粗粒度的類越來越龐大，程式碼越來越多，這個時候，我們就可以將這個粗粒度的類，拆分成幾個更細粒度的類。這就是所謂的持續重構

這幾條判斷原則，比起很主觀地去思考類是否職責單一，要更有指導意義、更具有可執行性：

• 類中的程式碼行數、函式或屬性過多，會影響程式碼的可讀性和可維護性，我們就需要考慮對類進行拆分；類依賴的其他類過多，或者依賴類的其他類過多，不符合高內聚、低耦合的設計思想，我們就需要考慮對類進行拆分；

• 私有方法過多，我們就要考慮能否將私有方法獨立到新的類中，設定為 public 方法，供更多的類使用，從而提高程式碼的複用性；

• 比較難給類起一個合適名字，很難用一個業務名詞概括，或者只能用一些籠統的 Manager、Context 之類的詞語來命名，這就說明類的職責定義得可能不夠清晰；

• 類中大量的方法都是集中操作類中的某幾個屬性，比如，在 UserInfo 例子中，如果一半的方法都是在操作 address 資訊，那就可以考慮將這幾個屬性和對應的方法拆分出來。

從另一個角度來看，當一個類的程式碼，讀起來讓你頭大了，實現某個功能時不知道該用哪個函數了，想用哪個函式翻半天都找不到了，只用到一個小功能要引入整個類（類中包含很多無關此功能實現的函式）的時候，這就說明類的行數、函式、屬性過多了。

實際上，不管是應用設計原則還是設計模式，最終的目的還是提高程式碼的可讀性、可擴充套件性、複用性、可維護性等。我們在考慮應用某一個設計原則是否合理的時候，也可以以此作為最終的考量標準。