**對於單功能的類來講，比較容易遵循srp，比如：把string轉換為datetime型別的工具類。理解srp的難點在於在多功能類的情形，即不容易理解多功能與單變化的矛盾。讓我們先來看乙個modem類的例子，modem具有4個功能：撥號，結束通話，傳送資料，接收資料： **
class modem
public void hangup()
public void send(char adata)
public char receive()
}
**我們先來考察一下modem類的變化點，並將其分為兩類：1.modem類的內部細節變化，比如dial、hangup、send、receive等具體實現發生了變化；2.modem類整體性的變化，比如modem類需要增加poweron和poweroff方法。上面的modem類具有多個變化點，不符合srp。 **
inte***ce idialable
class dialer : idialable}
class modem
private idialable m_dialer;
… //hangup, send, receive類似
}
類只有乙個變化的原因 >> 乙個變化只影響乙個類 >> 變化只影響其相應層次的類
設計模式原則 單一職責原則
定義 乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。即 不要存在多於乙個導致類變更的原因。通俗的說，就是乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 ...
設計模式原則 單一職責原則
對類來說的，即乙個類應該只負責一項職責。假如類a負責多項職責，當其中一項職責需求發生變更時，可能對其他職責的執行造成影響。例如 類a負責實現 訂單資料持久化 職責 和 使用者資料持久化 職責，那麼當我們需要修改 使用者資料持久化 需求時，由於 糅雜在乙個類裡，可能會對 訂單資料持久化 的職責造成影響...
設計模式原則 單一職責原則
1.概念 對類來說的，即乙個類應該只負責一項職責。如類a負責兩個不同職責 職責1，職責2。當職責1需求變更而改變a時，可能造成職責2執行錯誤，所以需要將類a的粒度分解為a1，a2。2.問題的提出 package com.atguigu.principle.singleresponsibility p...