最近在看一点设计模式的内容,在说23种设计模式之前,先要谈谈设计模式的六大原则,当然也有种说法是面向对象的六大原则,今天我们先谈谈单一职责原则。
一、定义
单一职责原则(Single Responsibility Principle)的定义是:一个类,应该只有一个引起它变化的原因。说白了,就是让一个类只负责一件事,将关联性强的内容聚合到一个类中。
二、代码示例
首先我们有一个用户信息类(接口)(IUserInfo.java)
public interface IUserInfo {
void getId();
void setId(int id);
void getName();
void setName(String name);
void getPassword();
void setPassword(String password);
void addUser(int id, String name, String password);
void deleteUser(int id);
}
下面是它的UML图:
看到上面的代码,很多人可能就说了,这个代码有问题啊,怎么可以将业务对象和业务逻辑的内容放到一个类中,业务对象和业务逻辑都会引起IUserInfo类的变化,上面的代码就违反了单一职责原则。
那我们按照单一职责的要求，我们要怎么改呢?那就是让一个类只做一件事,我们对上面的代码做如下的变化:
public interface IUserBo {
void getId();
void setId(int id);
void getName();
void setName(String name);
void getPassword();
void setPassword(String password);
}
public interface IUserBiz {
void addUser(int id, String name, String password);
void deleteUser(int id);
}
上面,我们将IUserInfo拆分为了IUserBo 和 IUserBiz,然后让IUserBiz在适当时候去操作IUserBo即可。
经过上面的修改,我们就实现了两个类的单一职责,也就是让引起他们变化原因只有一种,并且让相关性强的内容聚合在一个类内部。
三、优点
通过上面简单的例子,我们来总结一下单一职责原则的优点
1 . 类的复杂性降低,由于我们让每个类的职责单一,这样每个类职责清楚,定义明确
2 . 可读性提高了,复杂性降低了,类更便于维护
3 . 变更的风险降低了,需求一直在变,使用单一职责,只需要修改一个接口及其实现类,对其他类和接口没有影响
四、疑惑
看了上面的内容,可能有人觉得例子这么简单,而且说了半天貌似只是接口职责单一,类的职责并不是单一的。对，确实是这样。
首先,对于职责的划分这个是人为因素,可能每个人都有不同的看法,这种划分没有一个标准答案,因项目和环境而异。我们只需要尽量让一个类的职责清楚,让引起这个类变化的原因只有一个即可。但其实总是很难做到的,随着项目经验的增加,可能才会让我们设计的类越来越完善。我们要保证接口职责单一,类的职责尽量单一即可。
