本想把SOLID五大原則整理成一篇，放假在即，發現時間有點來不及了，只能分開來寫。
要構建一個良好的軟件系統，整潔的代碼和整潔的架構缺一不可。而我們在實際開發過程中，常常無視設計原則，“隨心所欲”地編程，當然，好的軟件系統需要工程師經驗的積累和認知的升級。
SOLID原則是面向對象軟件設計五大原則(SRP、OCP、LSP、ISP、DIP)的首字母縮寫，這些原則會讓我們的軟件更加健壯和穩定，並能最大限度地降低構建和維護一個系統所需的人力資源和時間成本。今天我們就按照字母順序，介紹第一個原則 — SRP原則(單一職責原則)。
SRP全稱是The Single Responsibility Principle，基於康威定律的一個推論，即一個軟件系統的最佳結構高度依賴於開發這個系統的組織的內部結構。這樣，每個軟件模塊都有且只有一個需要被改變的理由，也就是任何一個軟件模塊都應該只對某一類行爲者負責。具體到類的設計，就是讓一個類只承擔一種責任，不同的職責需要分離出來放在不同的類中，這樣，一個職責需要修改的時候，不會影響到另外的功能。
一個反例：
以下是一個僱員類，包含了財務部門需要的功能calculatePay(),和人力資源部門需要的功能reportHours()，這就把兩類行爲耦合在了一起，當一個部門修改了自己所需的功能之後，就有可能導致另外一個部門所需功能受到影響。
class Employee
{
//employee data
//some shared basic functions
calculatePay(); //財務部門功能
reportHours(); //人力資源部門功能
};
例如calculatePay()和reportHours()都依賴於同一個計算工時的函數regularHours()，當人力資源團隊需要修改工時計算方法時，regularHours()就會被修改，而財務部門是不知道這一修改的，calculatePay()調用regularHours()時，就可能得到錯誤的薪資數據，從而可能給公司造成極大的經濟損失。
解決方法：
一種最直觀的解決方法是，將以上兩種職責拆分到兩個類PayCalculator和HourReporter中，這兩個類共享一個簡單的、不包含重要功能函數的EmployeeData類，兩個類只包含各自職責內的功能函數，互不可見，如此，對一個功能的修改，其影響只在自己類的範圍內，而不會影響到其他類的功能。
class PayCalculator
{
EmployeeData employee_data;
calculatePay();
//some basic functions
};
class HourReporter
{
EmployeeData employee_data;
reportHours();
//some basic functions
};
SRP原則主要討論的是函數和類之間的關係。在組件層面，我們可將其稱爲共同閉包原則(CCP)；而在架構層面，SRP則爲架構邊界的劃分奠定了基礎。