单一职责原则(Single Responsibility Principle)

在软件设计、编码过程中有几个基本原则即SOLID原则，学习理解能够帮忙我们写出更健壮的代码。SOLID是五个基本原则的首字母。这五个原则如下：

• Single responsibility

• Open–closed

• Liskov substitution

• Interface segregation

• Dependency inversion

此篇来学习一下单一职责原则（Single responsibility）

相信很多人都听过单一职责原则（Single Responsibility Principle），那么什么是单一职责原则，怎么才算单一职责原则呢，单一职责原则又有什么好处呢。

记得当初刚开始进入项目组做需求的时候，完全不清楚什么设计模式、架构。一个问题单就困扰很久，慢慢搬砖越来越多，对项目的代码结构、业务有了一定的了解之后，回头看看自己写的代码，真是不忍直视。有一次写发送邮件的代码，将组装邮件内容、附件、发送等全部柔和在一个类里面，然后一位老大哥给review代码的时候就发现问题了，说你这个类写的太乱了，把什么都写在一个类里面了，完全不符合"单一职责原则"，当时那个脸红啊，赶紧虚心请教。

什么是单一职责原则呢？

我们来看看定义：一个类应该有且仅有一种原因引起改变（A class should have only one reason to change）。

一个职责就是一种会引起类的改变的原因，即如果我们有两种情况（原因）会改变一个类，那么我们就需要把这个类拆分成两个。如果一个类有多个职责，那么当其中一个职责状态改变，那么可能会影响到其他的职责。比如下面这段代码：

// 单一职责？
interface IEmail {
    public void setSender(String sender);

    public void setReceiver(String receiver);

    public void setContent(String content);
}

class Email implements IEmail {

    // set sender;
    public void setSender(String sender) {
    }

    // set receiver;
    public void setReceiver(String receiver) {
    }

    // set content;
    public void setContent(String content) {
    }
}

IEmail是一个接口，Email是一个简单的电子邮件类，保存了发送者，接受者，和邮件内容。看上去好像没什么问题，首先不管怎么样，都会有发送者和接收者，对应就是email，比如写信，一定是有写信人和收信人，但是邮件内容可能会变化，比如说，我们现在的内容是字符串，但是字符串无法实现丰富多彩的样式，随着业务的发展，将来可能要支持HTML、markdown等其他的格式，这个时候就需要修改IEmail和Email，可能会有类似这样的setContent(HTMLContent content)。

如果我们希望实现单一职责模式呢？是否要把content和sender, receiver拆分开呢。

我们可以建立新的接口和类–IContent和Content，来拆分原来的两个职责。具体代码如下：

// 单一职责原则 - 将原来的content改为IContent
interface IEmail {
    public void setSender(String sender);

    public void setReceiver(String receiver);

    public void setContent(IContent content);
}

interface IContent {

}

class Email implements IEmail {
    // set sender;
    public void setSender(String sender) {
    }

    // set receiver;
    public void setReceiver(String receiver) {
    }

    // set content;
    public void setContent(IContent content) {
    }
}

class Content implements IContent {

}

这样修改以后，后面不管Content改成什么样的形式，都可以很方便的扩展，比如说可以

class Content implements IContent {

}

class HTMLContent implements IContent {

}

class MarkDownContent implements IContent {
    
}

这样扩展起来是不是很方便呀。

单一职责原则的优点：

• 降低类的复杂度
• 提高可扩展性，以及类的可读性

我们引用《The UNIX Philosophy》书中的两条：

一：小即是美。

二：让程序只做好一件事。