單一職責原則的定義：
只能有乙個原因引起類的變更
單一職責原則的優點：
1.類的複雜性降低， 實現什麼職責都有清晰明確的定義；
2.可讀性提高， 複雜性降低， 那當然可讀性提高了；
3.可維護性提高， 可讀性提高， 那當然更容易維護了；
4.變更引起的風險降低， 變更是必不可少的， 如果介面的單一職責做得好， 乙個介面修改只對相應的實現類有影響， 對其他的介面無影響， 這對系統的擴充套件性、 維護性都有非常大的幫助。
單一職責原則的總結：
單一職責原則並不是絕對的，也要視情況而定，和專案的工期，成本，人員水平息息相關。不過乙個介面的方法一定要做到單一職責，因為如果做不到的話一旦介面或者方法發生改變那麼相應的實現者或者呼叫者也要相應的做出改動，對系統的影響比較大，可維護性和可擴充套件性大大降低。而對於類則盡量做到只有乙個原因發生變動，因為系統的變更是無法避免的，一旦發生變更如果能做到只增加相應的介面而對應的類只需要實現該介面那麼還是比較理想的。
舉例：比如乙個**介面，它有4個方法，乙個是打**，乙個是傳送簡訊，乙個是傳送彩信，乙個是上網。
所有繼承這個介面的類都要實現這4個介面，問題是有的**是不能傳送彩信的，比如諾基亞的黑白機，
有的**是不能上網的。但是這些**都要實現一些它其實不能實現的方法，而且每次這個介面增加乙個方法他它們都要實現，比如藍芽，無線傳輸等。
因為乙個介面的改變會改變他所有的實現類，這樣的話即使是黑白機也要實現傳送彩信，上網和無線傳輸的功能，這樣的話程式就會變的比較混亂。例如有時候呼叫者明明呼叫了乙個傳送彩信的介面卻發現根本沒有傳送出去，後來才發現原來是這個手機不支援 。程式的結構變的非常的模糊，不夠清晰明了，我們有時候甚至不能確定某些功能是否可以使用，同時也給後期的維護和擴充套件帶來了很多麻煩，因為一旦改變某個功能就可能需要對應的變更其他依賴於該功能的模組，即使這些模組並不需要這些功能。這就是不遵循單一職責原則帶來的壞處。
那麼試著想想如果我們在一開始就將這個介面拆分為3個介面，第乙個介面有打**和傳送簡訊的功能，另外兩個介面分別只有乙個方法，那就是傳送彩信和上網，他們可以繼承第乙個介面也可以不繼承，看具體情況。
那麼黑白機就可以實現第一介面，彩屏手機可以實現第二個能傳送彩信的介面，智慧型手機實現第三個能上網的介面，這樣一來程式的功能就比較清晰了，因為每個類只實現自己可以實現的方法。這樣呼叫者也可以清楚的知道自己呼叫物件的某些功能確實是可用的。可擴充套件性和可維護性也大大提高，每次的變更都只針對於那些確實需要變更的模組，而不會發生做一些小的功能變更就要改一大片**的情況。
設計模式原則 單一職責原則
定義 乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。即 不要存在多於乙個導致類變更的原因。通俗的說，就是乙個類只負責一項職責。問題由來 類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...