单一职责原则(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》书中的两条：

一：小即是美。

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

单一职责原则(Single Responsibility Principle)相关推荐

软件设计原则（二）单一职责原则 -Single Responsibility Principle
SRP,Single Responsibility Principle: There should never be more than one reason for a class to chang ...
设计模式原则篇:(1)单一职责原则--Single Responsibility Principle
上篇文章提及到设计模式中应遵循的设计原则,并且列出了设计模式中应当遵循的六大原则. 次篇文章主要讨论单一职责原则. 单一职责原则(SRP): 不要存在多于一个导致类变更的原因.简单的讲,就是一个类或接 ...
单一职责原则(SIngel Responsibility Principle SRP)
SRP 用原话解释就是 There should never be more than one reason for a class to change 翻译一下也就是有且只有一个原因引起该类的变 ...
面向对象设计之单一职责原则（Simple-Responsibility Principle）
单一职责原则: 一个类只负责一个功能领域中的相应职责,即就一个类而言,应该只有一个引起它变化的原因. 好处: 降低类的复杂度,一个类只负责一项职责,其逻辑肯定比负责多项职责简单的多复杂度低,可读性 ...
面向对象设计原则之一：单一职责原则
单一职责原则(Single Responsibility Principle SRP) There should never be more than one reason for a class t ...
设计模式---面向对象设计原则之单一职责原则
单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小.单一职责原则定义如下: 单一职责原则(Single Responsibility Principle, SRP):一个类只负责一个功能领 ...
设计模式之禅之单一职责原则
声明:本文为阅读秦小波所写的<设计模式之禅>所写小结,文章内容可能有部分引述此书. 单一职责原则(Single Responsibility Principle) 1.定义: 在接口 ...
设计模式七大原则：单一职责原则
设计模式目的软件设计模式(Design pattern),又称设计模式,是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证 ...
设计模式-单一职责原则-实践运用
单一职责原则-概念 1.单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小. 2.单一职责原则定义如下: 单一职责原则(Single Responsibility Principle, S ...

单一职责原则(Single Responsibility Principle)

单一职责原则(Single Responsibility Principle)相关推荐

最新文章

热门文章