前言Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从Object Menter
得到。
本文介绍“Principles of OOD”中的单一职责原则：Single Responsibility Principle (SRP)。
可以从这里查看Single Responsibility Principle (SRP)的原文
。
概要
There should never be more than one reason for a class to change.永远不要让一个类存在多个改变的理由。
换句话说，如果一个类需要改变，改变它的理由永远只有一个。如果存在多个改变它的理由，就需要重新设计该类。
SRP（Single Responsibility Principle）原则的核心含意是：只能让一个类有且仅有一个职责。这也是单一职责原则的命名含义。
为什么一个类不能有多于一个以上的职责呢？
如果一个类具有一个以上的职责，那么就会有多个不同的原因引起该类变化，而这种变化将影响到该类不同职责的使用者（不同用户）：
1，一方面，如果一个职责使用了外部类库，则使用另外一个职责的用户却也不得不包含这个未被使用的外部类库。
2，另一方面，某个用户由于某个原因需要修改其中一个职责，另外一个职责的用户也将受到影响，他将不得不重新编译和配置。
这违反了设计的开闭原则，也不是我们所期望的。
职责的划分既然一个类不能有多个职责，那么怎么划分职责呢？
Robert.C Martin给出了一个著名的定义：所谓一个类的一个职责是指引起该类变化的一个原因。
If you can think of more than one motive for changing a class, then that class has more than one responsibility.如果你能想到一个类存在多个使其改变的原因，那么这个类就存在多个职责。
Single Responsibility Principle (SRP)的原文
里举了一个Modem的例子来说明怎么样进行职责的划分，这里我们也沿用这个例子来说明一下：
SRP违反例：
Modem.java
interface Modem {
public void dial(String pno); //拨号
public void hangup(); //挂断
public void send(char c); //发送数据
public char recv(); //接收数据
}
咋一看，这是一个没有任何问题的接口设计。但事实上，这个接口包含了2个职责：第一个是连接管理（dial, hangup）；另一个是数据通信（send, recv）。很多情况下，这2个职责没有任何共通的部分，它们因为不同的理由而改变，被不同部分的程序调用。
所以它违反了SRP原则。
下面的类图将它的2个不同职责分成2个不同的接口，这样至少可以让客户端应用程序使用具有单一职责的接口：
让ModemImplementation 实现这两个接口。我们注意到，ModemImplementation又组合了2个职责，这不是我们希望的，但有时这又是必须的。通常由于某些原因，迫使我们不得不绑定多个职责到一个类中，但我们至少可以通过接口的分割来分离应用程序关心的概念。
事实上，这个例子一个更好的设计应该是这样的，如图：
小结Single Responsibility Principle (SRP)从职责（改变理由）的侧面上为我们对类（接口）的抽象的颗粒度建立了判断基准：在为系统设计类（接口）的时候应该保证它们的单一职责性。
