设计模式之禅01单一职责原则
单一职责原则
1.1 我是“牛”类,我可以担任多职吗
单一职责原则,英文名称是Single Responsibility Principle,简称是SRP,定义是应该有且仅有一个原因引起类的变更。
什么是类的职责,以及怎么划分类的职责?
举例:rbac模型
这个接口设计的存在问题:用户属性和用户行为没有分开
把用户信息抽取成一个BO(Business Object,业务对象),把行为抽取成一个Biz(Business Logic,业务逻辑),我们面向接口编程,所以产生的UserInfo对象可以当成IUserBO接口使用,也可以录成IUserBiz接口使用
IUserInfo userInfo = new UserInfo();
IUserBO userBO = (IUserBO)userInfo;
userBO.setPassword("abc");
IUserBiz userBiz = (IUserBiz)userInfo;
userBiz.deleteUser();
在实际使用中,我们更倾向于使用两个不同的类或接口,如下:
1.2 绝杀技,打破你的传统思维
举例:电话设计
这么设计的问题是IPhone接口不只有一个职责,分别为:一个是协议管理,一个是数据传送。
这样设计引起类间耦合过重、类的数量增加,人为地增加了设计的复杂性
这样设计,一个类实现两个接口,把两个职责融合在一个类中。
单一职责原则的好处
实现什么职责都有清晰明确的定义,这样类的复杂性降低,可读性提高,可维护性提高
1.3 我单纯,所以我快乐
单一职责适用于接口、类,同时也适用于方法。
要修改用户名称,就调用changeUserName方法;要修改家庭地址,就调用changeHomeAddress方法;要修改单位电话,就调用changeOfficeTel方法。每个方法的职责非常清晰明确,不仅开发简单,而且日后的维护也非常容易。
1.4 最佳实践
大部分情况下类设计都是与单一职责相违背的,类的单一职责受到非常多因素的制约,现实你必须去考虑项目工期、成本、人员技术水平、硬件情况、网络情况甚至有时候还要考虑政府政策、垄断协议等因素。
对于单一职责原则,建议是接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化。
参考:
- 《设计模式之禅》第2版