您的位置:首页 > 编程语言 > Java开发

Java设计模式之单一职责原则(Single Responsibility Principle)

2018-02-05 00:00 567 查看
摘要: 单一职责原则(Single responsibility principle)规定每个类都应该有一个单一的功能,并且该功能应该由这个类完全封装起来。

相信很多人都听过单一职责原则(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》书中的两条:

一:小即是美。

二:让程序只做好一件事。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
相关文章推荐