Single Resonsibility Principle
动机
在本文中， 职责是指进行一次改变的动机。SRP 规定如果我们有2个理由去修改一个类，那么我们应该将功能拆分到两个类中。每个类只承担一个职责，并且日后如果我们需要进行一个改动，我们就去负责相应职责的类中完成改动。当我们在承担多项职责的类中做改动时，就可能会影响到类中其他职责所关联的功能。
单一职责原则是一个简单直观的原则，不过在实践过程中有时却很难做好。
目的
一个类应该有且仅有一个改变的理由。
例子
假设我们需要一个对象来持有邮件消息。以下例子我们将使用 IEmail 接口。初看起来一切正常。再仔细看看的话我们可以发现 IEmail 接口和 Email 类拥有2个职责（改变的理由）。 一个是该类在一些邮件协议中的应用，如 pop3 或 imap。 如果必须支持其他协议，实例对象就要通过其他方式序列化，同时要增加代码来支持新的协议。另一个职责则是针对于邮件内容的。即使内容是字符串，我们以后可能要支持 HTML 或其他格式。
如果我们仅仅保留一个类，每次对其中一个职责的改变都可能影响到另一个。
- 增加新协议需要增加代码来解析和序列化各种字段类型
- 增加新的内容格式（如 html ）需要我们为应用的每个协议增加代码
// SRP -- Bad Example
interface IEmail{
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}
class Email implements IEmail{
public void setSender(String sender) {}
public void setReceiver(String receiver) {}
public void setContent(String content) {}
}
我们可以新建一个接口 IContent 和类 Content 来拆分职责。每个类仅有一个职责让我们的设计更加灵活：
- 增加新协议只引起
Email类的改变 - 增加新内容类型只引起
Content类的改变
// SRP -- Good Example
interface IEmail{
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}
interface IContent{
public String getAsString(); // used for serialization
}
class Email implements IEmail{
public void setSender(String sender) {}
public void setReceiver(String receiver) {}
public void setContent(IContent content) {}
}
总结
在软件应用的设计阶段单一职责原则是一种识别类的好方式。它也提醒你思考类可能发展的各种方向。只有在对应用该如何运行有清晰的全局认识之后，你才能将职责分离做好。
上一篇： 接口隔离原则
下一篇：里氏替换原则
目录： http://www.jianshu.com/p/af861220a6cc
