概述
單一職責原則（SRP：Singleresponsibilityprinciple）又稱單一功能原則，面向對象五個基本原則（SOLID）之一。它規定一個類應該只有一個發生變化的原因。該原則由羅伯特·C·馬丁（RobertC. Martin）於《敏捷軟體開發：原則、模式和實踐》一書中給出的。 馬丁表示此原則是基於湯姆·狄馬克(TomDeMarco)和Meilir Page-Jones的著作中的內聚性原則發展出的。
所謂職責是指類變化的原因。如果一個類有多於一個的動機被改變，那么這個類就具有多於一個的職責。而單一職責原則就是指一個類或者模組應該有且只有一個改變的原因。
原理
如果一個類承擔的職責過多，就等於把這些職責耦合在一起了。一個職責的變化可能會削弱或者一直這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當發生變化時，設計會遭受到意想不到的破壞。而如果想要避免這種現象的發生，就要儘可能的遵守單一職責原則。此原則的核心就是解耦和增強內聚性。
問題由來
之所以會出現單一職責原則就是因為在軟體設計時會出現以下類似場景：
T負責兩個不同的職責：職責P1，職責P2。當由於職責P1需求發生改變而需要修改類T時，有可能會導致原本運行正常的職責P2功能發生故障。也就是說職責P1和P2被耦合在了一起。
產生原因
沒有任何的程式設計人員不清楚應該寫出高內聚低耦合的程式，但是很多耦合常常發生在不經意之間，其原因就是：
職責擴散：因為某種原因，某一職責被分化為顆粒度更細的多個職責了。
解決辦法
遵守單一職責原則，講不同的職責封裝到不同的類或模組中。
實際套用
單一職責原則是軟體設計中最簡單的原則之一，也是最難正確運用的原則之一。人們會自然地把職責結合在一起。很多情況下軟體設計真正要做的許多工作正式發現職責並把職責相互分離。下面就介紹一些單一職責原則的一些常見實踐方法。
鑑別職責
每一個系統中的功能都表示了一個職責，這些職責可以映射到軟體模組（類）中，且應該儘可能的保證這些模組之間沒有功能上的重複。設計中每次應只關注一個職責。但這並不是說講其他的職責都拋之腦後，而是說當決定用某個模組來實現某個職責之後，只需全神貫注與該職責就可以了。從這個模組的角度出發，其他的職責都是不想關的。
信息隱藏
模組（類）擁有自己公開的接口，可以喝其他模組通信，同時模組也包含大量內部信息供自身使用。模組中只有接口暴露出的成員才能供其他模組使用。內部數據不是被徹底隱藏，就應被篩選後才能暴露給外部。這樣，每個模組仍可以使用固定的接口來通信，而同時不會受到修改具體實現的影響。
持久化
將持久、穩定的數據功能和頻頻變化的業務規則分離。這樣持久化的方式就不會因業務層的變化而頻繁變化了。最常見套用此思想的就是三層架構和MVC架構。
相關知識
單一職責原則並不是一個孤立的面向對象設計原則，它是面向對象設計五個基本原則（SOLID）之一。這些原則是：單一職責原則、開閉原則、里氏替換原則和依賴倒置原則。這些原則被一起套用時可以使一個軟體系統更易被維護和擴展。這些原則被典型的套用在測試驅動開發上，並且是敏捷開發以及自適應軟體開發等指導思想的重要組成部分。
發展歷史
單一職責原則是面向對象五個基本原則（SOLID）中的S。但他並不限於程式語言、設計方法，甚至超越了純粹的編程領域，還套用到了軟體架構的很多方面。而且其發展自1974年艾茲格·W·迪科斯徹 （EdsgerWybeDijkstra）在論文《In the Role of Scientific Thought》提出的分離關注點原則和湯姆·狄馬克(TomDeMarco)在論文《Structed Analsis and System Specification》中提出的內聚性原則。然而這兩個原則最初並不套用於面向對象設計，而是支持過程式編程（Procedural Programming）的理念。在過程式編程中，單一職責原則是依賴函式和過程實現的。
隨著面向對象編程（OOP）語言的出現，人們才開始用類來分離關注點。從而被羅伯特·C·馬丁（RobertC.Martin）總結出了單一職責原則。
發明人簡介
羅伯特·C·馬丁（RobertC.Martin）業內人稱Bob大叔，世界級軟體開發大師，著名軟體公司Object Mentor公司的創始人和總裁。曾擔任C++ Report雜誌主編多年，也是設計模式和敏捷開發運動的主要倡導者之一。
