单一职责就是指一个类应该专注于做一件事。现实生活中也存在诸如此类的问题:“一个人可能身兼数职,甚至于这些职责彼此关系不大,那么他可能无法做好所有职责内的事情,所以,还是专人专管比较好。”我们在设计类的时候,就应该遵循这个单一职责原则。
在有些人眼里,计算器就是一件东西,是一个整体,所以它把这个需求进行了抽象,最终设计为一个Calculator类,代码如下:
class Calculator{
public String calculate() {
Console.Write("Please input the first number:");
String strNum1 = Console.ReadLine();
Console.Write(Please input the operator:");
String strOpr= Console.ReadLine();
Console.Write("Please input the second number:");
String strNum2 = Console.ReadLine();
String strResult = "";
if (strOpr == "+"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) + Convert.ToDouble(strNum2));
}
else if (strOpr == "-"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) – Convert.ToDouble(strNum2));
}
else if (strOpr == "*"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) * Convert.ToDouble(strNum2));
}
else if (strOpr == "/"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) / Convert.ToDouble(strNum2));
}
Console.WriteLine("The result is " + strResult);
}
}
另外,还有一部分人认为:计算器是一个外壳和一个处理器的组合。
class Appearance{
public int displayInput(String &strNum1,String &strOpr, String &strNum2) {
Console.Write("Please input the first number:");
strNum1 = Console.ReadLine();
Console.Write(Please input the operator:");
strOpr= Console.ReadLine();
Console.Write("Please input the second number:");
strNum2 = Console.ReadLine();
return 0;
}
public String displayOutput(String strResult) {
Console.WriteLine("The result is " + strResult);
}
}
class Processor{
public String calculate(String strNum1,String strOpr, String strNum2){
String strResult = "";
if (strOpr == "+"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) + Convert.ToDouble(strNum2));
}
else if (strOpr == "-"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) – Convert.ToDouble(strNum2));
}
else if (strOpr == "*"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) * Convert.ToDouble(strNum2));
}
else if (strOpr == "/"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) / Convert.ToDouble(strNum2));
}
return strResult;
}
}
为什么这么做呢?因为外壳和处理器是两个职责,是两件事情,而且都是很容易发生需求变动的因素,所以把它们放到一个类中,违背了单一职责原则。
比如,用户可能对计算器提出以下要求:
第一,目前已经实现了“加法”、“减法”、“乘法”和“除法”,以后还可能出现“乘方”、“开方”等很多运算。
第二,现在人机界面太简单了,还可能做个Windows计算器风格的界面或者Mac计算器风格的界面。
所以,把一个类Calculator 拆分为两个类Appearance和Processor,一个类做一件事情,这样更容易应对需求变化。如果界面需要修改,那么就去修改Appearance类;如果处理器需要修改,那么就去修改Processor类。
我们再举一个邮件的例子。我们平常收到的邮件内容,看起来是一封信,实际上内部有两部分组成:邮件头和邮件体。电子邮件的编码要求符合RFC822标准。
第一种设计方式是这样:
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) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
这个设计是有问题的,因为邮件头和邮件体都有变化的可能性。
1、邮件头的每一个域的编码,可能是BASE64,也可能是QP,而且域的数量也不固定。
2、邮件体中封装的邮件内容可能是PlainText类型,也可能是HTML类型,甚至于流媒体。
所谓第一种设计方式违背了单一职责原则,里面封装了两种可能引起变化的原因。
我们依照单一职责原则,对其进行改进后,变为第二种设计方式:
interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}
interface IContent {
public String getAsString();
}
class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
有的资料把单一职责解释为:“仅有一个引起它变化的原因”。这个解释跟“专注于做一件事”是等价的。如果一个类同时做两件事情,那么这两件事情都有可能引起它的变化。同样的道理,如果仅有一个引起它变化的原因,那么这个类也就只能做一件事情。
单一职责原则的使用
A、一个设计合理的类,应该仅有一个可以引起它变化的原因,即单一职责,如果有多个原因可以引起它的变化,就必须进行分离;
B、在没有需求变化征兆的情况下,应用单一职责原则或其他原则是不明智的,因为这样会使系统变得很复杂,系统将会变成一堆细小的颗粒组成,纯属于没事找抽;
C、在需求能够预计或实际发生变化时,就应该使用单一职责原则来重构代码,有经验的设计师、架构师对可能出现的需求变化很敏感,设计上就会具有一定的前瞻性。
单一职责(SRP,Single Responsibility Principle)强调的是职责的分离,在某种程度上对职责的理解,构成了不同类之间耦合关系的设计关键,因此单一职责原则或多或少成为设计过程中一个必须考虑的基础性原则。
核心思想:
单一职责原则可以看做是低耦合,高内聚在面向对象原则上的引申,将职责定义为引起变化的原因,以提高内聚性来减少引起变化的原因。职责过多,可能引起它变化的原因就越多,这将导致依赖,相互之间就产生影响,从而极大的损伤其内聚性和耦合性。单一职责,通常意味着单一的功能,因此不要为类实现过多的功能点,以保证实体只有一个引起它变化的原因。
重构方法:
对于违反这一个原则的类应该进行重构,例如以Façade模式或Proxy模式分离职责,通过基本方法Extract Interface ,Extract Class 和Extract Method进行梳理。
案例分析:
MIS 系统中根据不同的权限进行数据增删改查的系统比比皆是,然而这正是一个比较常见的一种需求场景,先看设计图:
图2-2职责分离的设计
以上设计,DBManager类将对数据库的操作和用户权限的判断封装在一个类中去实现,看小段代码:
public void Add() { if(GetPermission(id) == "CanAdd") { Insert();// 可以添加数据 ,数据库操作逻辑代码 } }
现在GetPermission(string
按照单一职责原则,一个类只有一个引起它变化的原因,下面我们选择合适的方法进行重构有缺陷的设计,在此我们使用Proxy模式来解决类太累的问题,重构之后的设计图:
图2-2职责分离的设计
以Proxy模式重构之后,有效的实现了职责分离,DBManager专注于执行数据库的操作,下面来看修改之后的代码:
public class DBManager:IDAO { public void Add() { throw new NotImplementedException(); } public void View() { throw new NotImplementedException(); } public void Delete() { throw new NotImplementedException(); } }
而DBManagerProxy只需关注于数据库逻辑的操作:
public class DBManagerProxy:IDAO { private IDAO dbdaoInstance; public DBManagerProxy(IDAO dbdao) { dbdaoInstance = dbdao; } string GetParmession(string id) { // 判断逻辑 return "Add"; } public void Add() { if (GetParmession("Add")=="ADD") { // 权限操作 } } public void View() { throw new NotImplementedException(); } public void Delete() { throw new NotImplementedException(); } }
小结:
在实例中IDAO 体现了设计模式中的重要原则:依赖倒置原则(DIP),通过DBManagerProxy代理类实现了职责分离,DBManager仅有一个引起变化的原因,就是数据操作的需求变更,而权限的变更和修改不对DBManager 造成任何影响,体现了单一职责原则。
适用场景:
一个类只有一个引起它变化的原因,否则就应当考虑重构。
SRP由引起变化的原因决定,而不由功能决定。虽然职责常常引起变化的轴线,但有时就未必,应该适当考虑。
可以通过Facade模式或Proxy模式进行职责分离。
个人心得和大家共勉:
在实际的项目过程中间要不断的去重构自己的代码,平时多看好书,不过现在好书不多(市场上也就那么几本),要多去思考书中作者写的每一个示例,举一反三,会逐步的提高自己的设计能力和分析能力。
问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。
解决方案:遵循单一职责原则。分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1时,不会使职责P2发生故障风险;同理,当修改T2时,也不会使职责P1发生故障风险。
举例说明,用一个类描述动物呼吸这个场景:
class Animal{
}
public class Client{
}
运行结果:
牛呼吸空气
羊呼吸空气
猪呼吸空气
程序上线后,发现问题了,并不是所有的动物都呼吸空气的,比如鱼就是呼吸水的。修改时如果遵循单一职责原则,需要将Animal类细分为陆生动物类Terrestrial,水生动物Aquatic,代码如下:
class Terrestrial{
}
class Aquatic{
}
public class Client{
}
运行结果:
牛呼吸空气
羊呼吸空气
猪呼吸空气
鱼呼吸水
我们会发现如果这样修改花销是很大的,除了将原来的类分解之外,还需要修改客户端。而直接修改类Animal来达成目的虽然违背了单一职责原则,但花销却小的多,代码如下:
class Animal{
}
public class Client{
}
可以看到,这种修改方式要简单的多。但是却存在着隐患:有一天需要将鱼分为呼吸淡水的鱼和呼吸海水的鱼,则又需要修改Animal类的breathe方法,而对原有代码的修改会对调用“猪”“牛”“羊”等相关功能带来风险,也许某一天你会发现程序运行的结果变为“牛呼吸水”了。这种修改方式直接在代码级别上违背了单一职责原则,虽然修改起来最简单,但隐患却是最大的。还有一种修改方式:
class Animal{
}
public class Client{
}
可以看到,这种修改方式没有改动原来的方法,而是在类中新加了一个方法,这样虽然也违背了单一职责原则,但在方法级别上却是符合单一职责原则的,因为它并没有动原来方法的代码。这三种方式各有优缺点,那么在实际编程中,采用哪一中呢?其实这真的比较难说,需要根据实际情况来确定。我的原则是:只有逻辑足够简单,才可以在代码级别上违反单一职责原则;只有类中方法数量足够少,才可以在方法级别上违反单一职责原则;
l
l
l
需要说明的一点是单一职责原则不只是面向对象编程思想所特有的,只要是模块化的程序设计,都需要遵循这一重要原则。
我们知道,在面向对象设计中要做到高内聚低耦合。而单一职责原则就是实现高内聚低耦合的最好办法。面向对象设计中单一职责原则是指:
{
public :
};
class
{
public :
private :
};
{
public :
};
class
{
public :
private :
};
class
{
public :
};
class
{
public :
private :
};
单一职责原则(Single Responsibility Principle),简称SRP。
定义:
There should never be more than one reason for a class to change.
应该有且仅有一个原因引起类的变更。
有时候,开发人员设计接口的时候会有些问题,比如用户的属性和用户的行为被放在一个接口中声明。这就造成了业务对象和业务逻辑被放在了一起,这样就造成了这个接口有两种职责,接口职责不明确,按照SRP的定义就违背了接口的单一职责原则了。
下面是个例子:
package com.loulijun.chapter1;
public interface Itutu {
}
上面的例子就存在这个问题,身高、体重属于业务对象,与之相应的方法主要负责用户的属性。而吃饭、上网是相应的业务逻辑,主要负责用户的行为。但是这就会给人一种不知道这个接口到底是做什么的感觉,职责不清晰,后期维护的时候也会造成各种各样的问题。
解决办法:单一职责原则,将这个接口分解成两个职责不同的接口即可
ItutuBO.java:负责tutu(涂涂,假如是个人名)的属性
package com.loulijun.chapter1;
public interface ItutuBO {
}
ItutuBL.java:负责涂涂的行为
package com.loulijun.chapter1;
public interface ItutuBL {
}
这样就实现了接口的单一职责。那么实现接口的时候,就需要有两个不同的类
TutuBO.java
package com.loulijun.chapter1;
public class TutuBO implements ItutuBO {
}
TutuBL.java
package com.loulijun.chapter1;
public class TutuBL implements ItutuBL {
}
这样就清晰了,当需要修改用户属性的时候只需要对ItutuBO这个接口来修改,只会影响到TutuBO这个类,不会影响其他类。
那么单一职责原则的意义何在呢?
1、降低类的复杂性,实现什么样的职责都有清晰的定义
2、提高可读性
3、提高可维护性
4、降低变更引起的风险,对系统扩展性和维护性很有帮助
但是、使用单一职责原则有一个问题,“职责”没有一个明确的划分标准,如果把职责划分的太细的话会导致接口和实现类的数量剧增,反而提高了复杂度,降低了代码的可维护性。所以使用这个职责的时候还要具体情况具体分析。建议就是接口一定要采用单一职责原则,实现类的设计上尽可能做到单一职责原则,最好是一个原因引起一个类的变化。
认识单一职责原则
单一职责原则是面向对象设计中最重要的原则之一,而面向对象最基础的东西就是类和对象的使用,而单一职责可以说是对类和对象的一种要求,也就是要求类应该有且仅有一个引起它变化的原因。
开闭原则是指一个类,只有一个引起它变化的原因。有且只有一个职责。每一个职责都是变化的一个轴线,如果一个类有一个以上的职责,这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时,可能会影响其它的职责。另外,多个职责耦合在一起,会影响复用性。
单一职责原则由来
谈到单一职责原则的由来不得不说面向对象,也不得不说需求是在不断变化,因为软件需求唯一的不变的真理就是软件需求一定会变化,因为需求变化,所以我们就要用到面向对象的设计思想,而面向对象的要求就是复用、能用最小的代价应对变化、不用改变现有代码就能满足扩展(其实这就上一篇博客中说的《开闭原则》)。在面向对象的要求下,许多人在这些问题上思考了很多,也花费了很大努力来实现这几点,所以单一职责原则就在这样的背景下诞生了。
单一职责原则的好处
① 单一职责原则提供了一个编写程序的标准,也就是让类的复杂性降低,实现什么职责都有清晰明确的定义
② 在可读性和可维护性上得到了提高,因为类的职责单一,对类的阅读,类之间的调用关系都是清晰明确的。
项目中分析单一职责原则
在这里引用一个比较经典的例子,就是图形计算程序和图形绘制程序调用Area()方法和Draw()方法的例子。
例子出处《开篇-模式和原则》:
图形计算程序只使用了正方形的Area()方法,永远没有使用Draw()方法,而它却和draw方法关联起来,这就违反了单一指责原则,如果将来有一天图形绘制程序导致draw发生变化,那就影响到了本来毫无关系的图形计算程序。
所以我们应该将不同的职责分配给不同的类,让每个类的职责单一,隔离变化
常言道
常言道:该你管的你管,不该你管的你别插手。