本想把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则为架构边界的划分奠定了基础。
