單一職責原則

單一職責原則是最簡單的物件導向設計原則，它用於控制類的粒度大小。（什麼是類的粒度？）

單一原則是實現低耦合、高內聚的指導方針。（什麼是低耦合、高內聚？）

單一職責原則的定義：

乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。

我理解的是乙個類只用來實現乙個功能或者一些總是同時發生改變的功能（即這些功能是乙個整體不可分割）

舉例：假設在類a的方法中，getconnection（）方法是用於連線資料庫，finduser（）用於查詢使用者資訊，displayuser（）用於使用者的圖表顯示。

可見類a承擔了很多職責，既包含資料庫相關的方法又包含查詢、顯示使用者的方法，若是其他類也要使用資料庫的連線或者查詢使用者資訊，**則不能實現重用。無論是修改資料庫連線的方式還是修改顯示使用者資訊的方式都需要修改該類，它擁有不止乙個引起它變化的原因，違背了單一職責原則，為使其滿足單一職責原則，對該類進行拆分：

dbutil：該類負責資料庫的連線

userdao：該類負責使用者資訊的增刪改查

displayuser：該類負責使用者的圖表顯示

這樣設計後每個類都只負責自己的職責，不會因為其他因素而變化，方便了**的重用和維護。

單一職責原則

定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...

單一職責原則

單一職責原則 乙個類，只有乙個引起它變化的原因。應該只有乙個職責。每乙個職責都是變化的乙個軸線，如果乙個類有乙個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當乙個職責發生變化時，可能會影響其它的職責。另外，多個職責耦合在一起，會影響復用性。例如 要實現邏輯和介面的分離。對於user類，裡...

單一職責原則

問題由來 一心二用，效率降低 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 專注做某件事情 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t2完成職責p2功能。這樣，當修改類t1...