======================================================================================
单一职责原则的英文名称是Single Responsibility Principle,简称是SRP。
在项目中,会用到用户、机构、角色管理这些模块,基本上使用的都是 RBAC模型(Role-Based Access Control,基于角色的访问控制,通过分配和取消角色来完成 用户权限的授予和取消,使动作主体(用户)与资源的行为(权限)分离)。用户有用户管理、修改用户的信息、增加机构(一个人属于多个 机构)、增加角色等信息和行为要维护,假如把这些写到一个接口中, 看看它的类图,如图1-1所示:
1-1:用户信息维护类图
这个类真的是足够糟糕的!用户的属性和行为都耦合到一块了。为什么不可以呢?因为如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类其它职责的能力,这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏。
所以应该把用户的信息抽取成一个BO(Business Object,业务对象),把行为抽取成一个 Biz(Business Logic,业务逻辑),按照这个思路对类图进行修正,如图1-2所示:
1-2:职责划分后的类图
重新拆封成两个接口,IUserBO负责用户的属性:职责是收集和反馈用户的属性信息;IUserBiz负责用户的行为:职责是完成用户信息的维护和变更。
看一看分拆成两个接口怎么使用呢?现在是面向接口编程,所以产生了这个UserInfo对象之后,当然既可以把它当IUserBO接口使用,也可以当IUserBiz接口使用。 要获得用户信息,就当是IUserBO的实现类;要是希望维护用户的信息,就把它当作IUserBiz 的实现类。比如:
IUserInfo userInfo = new UserInfo();
//要赋值了,把它作为一个纯粹的BO
IUserBO userBO = (IUserBO)userInfo;
userBO.setPassword(“abc”);
//要执行动作了,把它作为一个业务逻辑类
IUserBiz userBiz = (IUserBiz)userInfo;
userBiz.deleteUser();
为什么要把一个接口 拆分成两个呢?其实,在实际的使用中,更倾向于使用两个不同的类或接口:一个是 IUserBO,一个是IUserBiz,类图如图1-3所示:
1-3:项目中经常采用的SRP类图
以上把一个接口拆分成两个接口的动作,就是依赖了单一职责原则,那什么是单一 职责原则呢?
单一职责原则的定义是:应该有且仅有一个原因引起类的变更。
===========================================================================================
单一职责原则看起来似乎比较简单,实际上软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离。在实际的业务当中去把那些职责区分出来不是那么简单。
比如,生活中常用的电话,通话的时候有4个过程发生:拨号、通话、回 应、挂机,写一个接口,其类图如图1-4所示:
1-4:电话类图
接口的代码:
public interface IPhone {
//拨通电话
public void dial(String phoneNumber);
//通话
public void chat(Object o);
//通话完毕,挂电话
public void hangup();
}
这个类看起来是没什么问题的。单一职责原则 要求一个接口或类只有一个原因引起变化,也就是一个接口或类只有一个职责,它就负责一 件事情,上面的接口只负责一件事情吗?是只有一个原因引起变化吗?并不是!
面试题总结
其它面试题(springboot、mybatis、并发、java中高级面试总结等)
总结
其它面试题(springboot、mybatis、并发、java中高级面试总结等)
[外链图片转存中…(img-TEqW5hEp-1720130004094)]
[外链图片转存中…(img-kjVq0xD1-1720130004095)]
[外链图片转存中…(img-jULxoQeE-1720130004096)]