单一职责原则（Single Responsibility Principle,SRP)定义如下:
一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。
另一种定义方式如下：
就一个类而言，应该仅有一个引起它变化的原因。
单一职责原则分析
T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2发生故障。
一个类（或者大到一个模块，小到方法）承担的职责越多，他被复用的可能性越小，而且如果一个类承担的职责过多，就相当于将这些职责耦合在一起，其中一个职责发生变化时，可能会影响其他职责的运作。
类的职责主要包括两个方面：数据职责和行为职责，数据职责通过其属性来体现，而行为职责通过其方法来实现。
单一职责是实现高内聚低耦合的指导方针，很多代码重构手法都能找到它的存在，它是简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。
遵循单一职责原则。分别建立两个类T1和T2，使T1完成职责P1的功能，T2完成职责P2的功能。这样当修改类T1时，不会使职责P2发生故障风险；同理当修改T2时，也不会使职责P1发生故障风险。
单一职责原则的核心思想是：一个类，最好只做一件事，只有一个引起它变化的原因。
单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将其职责定义为引起其变化的原因，以提高内聚性来减少引起其变化的原因。职责越多，可能引起变化的原因就越多，这将是致职责依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一职责通常意味着单一的功能，因此不要为类实现过多的功能点，以保证实体只有一个引起它变化的原因。
单一职责原则并不是绝对的
在软件编程过程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为什么出现这种现象？因为职责有扩散。所谓扩散，就是因为某种原因，职责P被分化为颗粒度更细的职责P1和P2。
比如：T只负责职责P，这样的设计是符合单一职责原则的。后来由于某种原因，也许是需求变更了，也许是程序设计者的境界变高了，需要将职责P细分为颗粒度更细的职责P1，P2，这时如果要使程序遵循单一职责原则需要将类T分解为两个类T1和T2，分别负责P1、P2两个职责。但是在程序已经写好的情况下，这样做简直太浪费时间了。所以，简单修改类T，用它来负责两个职责是比较不错的选择，虽然这样做有悖于单一职责原则。
单一职责原则的好处：类的复杂性降低，可读性提高，可维护性提高，变更引起的风险降低。
整合当然是一种很好的思想。比如Google最初的理想就是将一切的需求都整合的一个文本框里提交，用干净的页面来吸引用户，导致互联网的一场变革。但现在分类信息，垂直搜索又开始流行，这确实单一职责的思想体现。现在智能手机整合了很多功能的原因原因是：因DV,DC,MP3,MP4等产品的无时无刻也太大了，手机携带很方便，所以才有这样的过度产品，比如每样数码产品都缩小100倍，像放在包里的卡片，笔那么简单，而功能和质量不变，我们就会觉得很麻烦，而编程时，我们要在类职责分离上多思考，做到单一职责，这样代码才易维护，易扩展，易复用，灵活多样。