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) {}
}

总结

在软件应用的设计阶段单一职责原则是一种识别类的好方式。它也提醒你思考类可能发展的各种方向。只有在对应用该如何运行有清晰的全局认识之后，你才能将职责分离做好。

上一篇： 接口隔离原则
下一篇：里氏替换原则
目录： //www.greatytc.com/p/af861220a6cc