单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
在面向对象编程领域中，单一功能原则（Single responsibility principle）规定每个类都应该有一个单一的功能，并且该功能应该由这个类完全封装起来。所有它的（这个类的）服务都应该严密的和该功能平行（功能平行，意味着没有依赖）。
这个术语由罗伯特·C·马丁（Robert Cecil Martin）在他的《敏捷软件开发，原则，模式和实践》一书中的一篇名为〈面向对象设计原则〉的文章中给出。 [1] 马丁表述该原则是基于的《结构化分析和系统规格》[2]一书中的内聚原则（Cohesion）上。
马丁把功能（职责）定义为：“改变的原因”，并且总结出一个类或者模块应该有且只有一个改变的原因。一个具体的例子就是，想象有一个用于编辑和打印报表的模块。这样的一个模块存在两个改变的原因。第一，报表的内容可以改变（编辑）。第二，报表的格式可以改变（打印）。这两方面会的改变因为完全不同的起因而发生：一个是本质的修改，一个是表面的修改。单一功能原则认为这两方面的问题事实上是两个分离的功能，因此他们应该分离在不同的类或者模块里。把有不同的改变原因的事物耦合在一起的设计是糟糕的。
保持一个类专注于单一功能点上的一个重要的原因是，它会使得类更加的健壮。继续上面的例子，如果有一个对于报表编辑流程的修改，那么将存在极大的危险性，因为假设这两个功能存在于同一个类中，修改报表的编辑流程会导致公共状态或者依赖关系的改变，打印功能的代码会因此不工作。
1、官方定义
单一职责原则，英文缩写SRP，全称Single Responsibility Principle。
原始定义：There should never be more than one reason for a class to change。
官方翻译：应该有且仅有一个原因引起类的变更。简单点说，一个类，最好只负责一件事，只有一个引起它变化的原因。
1-2、什么是职责
职责定义为：变化的原因"(a reason for change)。
如果你能够想到多于一个的动机去改变类，那么这个类就具有多于一个的职责。
这条原则曾经被认为与内聚性(cohesion)相关。内聚性可以定义为：一个模块的组合元素之间的功能相关性。即对一个类来说，这个类是否只专心做一件事。
Robert Cecil Martin（"Bob"大叔）把职责定义为变化的原因，更能表达出该原则的特性。
2-2、违反单一职责原则有什么坏处？
如果一个类承担的职责过多，等于把这些职责耦合在了一起；一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。
这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。
3-2、不必分离两个总是同时变化的职责
如果应用程序的变化总是导致这两方面职责同时变化，那么就不必分离他们。 实际上，分离他们就会具有不必要的复杂性。
2.1、原理解释
上面的定义不难理解，引起类变化的原因不能多于一个。也就是说每一个类只负责自己的事情，此所谓单一职责。
我们知道，在OOP里面，高内聚、低耦合是软件设计追求的目标，而单一职责原则可以看做是高内聚、低耦合的引申，将职责定义为引起变化的原因，以提高内聚性，以此来减少引起变化的原因。职责过多，可能引起变化的原因就越多，这将是导致职责依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一职责通常意味着单一的功能，因此不要为类实现过多的功能点，以保证实体只有一个引起它变化的原因。
不管是从官方定义，还是对“单一职责”名称的解释，都能很好的理解单一职责原则的意义。其实在软件设计中，要真正用好单一职责原则并不简单，因为遵循这一原则最关键的地方在于职责的划分，博主的理解是职责的划分是根据需求定的，同一个类（接口）的设计，在不同的需求里面，可能职责的划分并不一样，为什么这么说呢？我们来看下面的例子。
为什么将不同的职责分离到单独的类中是如此的重要呢？
因为每一个职责都是一个变化的中心。当需求变化时，这个变化将通过更改职责相关的类来体现。
如果一个类拥有多于一个的职责，则这些职责就耦合到在了一起，那么就会有多于一个原因来导致这个类的变化。对于某一职责的更改可能会损害类满足其他耦合职责的能力。这样职责的耦合会导致设计的脆弱，以至于当职责发生更改时产生无法预期的破坏。
单一职责原则：一个类应该仅有一个引起它变化的原因。
即：管理复杂度，找出容易变化/改变的区域，隔离变化。
单一职责原则是最简单的原则之一，也是最难正确运用的原则之一，因为我们很容易把职责结合一起。
软件设计很重要的工作就是发现职责并把那些职责相互分离，我们平时或多或少的都使用到单一职责原则，如果开发中能关注到就更好了。
单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离。
单一职责原则告诉我们：一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。
单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验。
下面通过一个简单实例来进一步分析单一职责原则：
Sunny软件公司开发人员针对某CRM（Customer Relationship Management，客户关系管理）系统中客户信息图形统计模块提出了如图1所示初始设计方案：
图1 初始设计方案结构图
在图1中，CustomerDataChart类中的方法说明如下：getConnection()方法用于连接数据库，findCustomers()用于查询所有的客户信息，createChart()用于创建图表，displayChart()用于显示图表。
现使用单一职责原则对其进行重构。
在图1中，CustomerDataChart类承担了太多的职责，既包含与数据库相关的方法，又包含与图表生成和显示相关的方法。如果在其他类中也需要连接数据库或者使用findCustomers()方法查询客户信息，则难以实现代码的重用。无论是修改数据库连接方式还是修改图表显示方式都需要修改该类，它不止一个引起它变化的原因，违背了单一职责原则。因此需要对该类进行拆分，使其满足单一职责原则，类CustomerDataChart可拆分为如下三个类：
(1) DBUtil：负责连接数据库，包含数据库连接方法getConnection()；
(2) CustomerDAO：负责操作数据库中的Customer表，包含对Customer表的增删改查等方法，如findCustomers()；
(3) CustomerDataChart：负责图表的生成和显示，包含方法createChart()和displayChart()。
使用单一职责原则重构后的结构如图2所示：
具体模式应用：策略模式