「设计模式」六大原则之一:单一职责小结
Posted 小羊子说
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了「设计模式」六大原则之一:单一职责小结相关的知识,希望对你有一定的参考价值。
文章目录
「设计模式」六大原则系列链接:
「设计模式」六大原则之一:单一职责小结
「设计模式」六大原则之二:开闭职责小结
「设计模式」六大原则之三:里氏替换原则小结
「设计模式」六大原则之四:接口隔离原则小结
「设计模式」六大原则之五:依赖倒置原则小结
「设计模式」六大原则之六:最小知识原则小结
六大原则体现很多编程的底层逻辑:高内聚、低耦合、面向接口编程、面向抽象编程,最终实现可读、可复用、可维护性。
设计模式的六大原则有:
- Single Responsibility Principle:单一职责原则
- Open Closed Principle:开闭原则
- Liskov Substitution Principle:里氏替换原则
- Law of Demeter:迪米特法则(最少知道原则)
- Interface Segregation Principle:接口隔离原则
- Dependence Inversion Principle:依赖倒置原则
把这六个原则的首字母联合起来( L 算做一个)就是 SOLID (solid,稳定的),其代表的含义就是这六个原则结合使用的好处:建立稳定、灵活、健壮的设计。
本文介绍 SOLID 中的第一个原则:单一职责原则。
1.单一职责原则定义
单一职责原则 [Single Responsibility Principle 简称 SRP],又叫单一功能原则。
A class or module should have a single responsibility。
我们把它翻译成中文,那就是:一个类或者模块只负责完成一个职责(或者功能)。
就一个类而言,应该仅有一个引起它变化的原因。
所谓职责就是指类变化的原因,也就是业务需求。如果有一个类有多于一个的原因被改变,那么这个类就有超过两个及以上的职责。而单一职责原则约定一个应该有且只有一个改变业类的原因。
单一职责原则的核心就是解耦和增强内聚性。
一句话总结:一个类只干一件事。
应用实践:不要设计大而全的类,要设计粒度小、功能单一的类。换个角度来讲就是,一个类包含了两个或者两个以上业务不相干的功能,那我们就说它职责不够单一,应该将它拆分成多个功能更加单一、粒度更细的类。
2.如何理解单一职责原则(SRP)?
一个类只负责完成一个职责或者功能。不要设计大而全的类,要设计粒度小、功能单一的类。单一职责原则是为了实现代码高内聚、低耦合,提高代码的复用性、可读性、可维护性。
3. 如何判断类的职责是否足够单一?
不同的应用场景、不同阶段的需求背景、不同的业务层面,对同一个类的职责是否单一,可能会有不同的判定结果。实际上,一些侧面的判断指标更具有指导意义和可执行性,比如,出现下面这些情况就有可能说明这类的设计不满足单一职责原则:
-
类中的代码行数、函数或者属性过多;
会影响代码的可读性和可维护性,我们就需要考虑对类进行拆分(也就是重构)。
如果你是没有太多项目经验的编程初学者,实际上,我也可以给你一个凑活能用、比较宽泛的、可量化的标准,那就是一个类的代码行数最好不能超过 200 行,函数个数及属性个数都最好不要超过 10 个。
-
类依赖的其他类过多,或者依赖类的其他类过多;
不符合高内聚、低耦合的设计思想,我们就需要考虑对类进行拆分。
-
私有方法过多;
我们就要考虑能否将私有方法独立到新的类中,设置为 public 方法,供更多的类使用,从而提高代码的复用性。
-
比较难给类起一个合适的名字;
很难用一个业务名词概括,或者只能用一些笼统的 Manager、Context 之类的词语来命名,这就说明类的职责定义得可能不够清晰;
-
类中大量的方法都是集中操作类中的某几个属性。
4. 类的职责是否设计得越单一越好?
单一职责原则通过避免设计大而全的类,避免将不相关的功能耦合在一起,来提高类的内聚性。同时,类职责单一,类依赖的和被依赖的其他类也会变少,减少了代码的耦合性,以此来实现代码的高内聚、低耦合。但是,如果拆分得过细,实际上会适得其反,反倒会降低内聚性,也会影响代码的可维护性。
5. 应用体现
- android 中的架构演变思想运用体现:Android 里面 Activity 过于臃肿会让感觉很头大,MVP, MVVM等框架都是为了让 Activity 变得职责单一。
- 架构分层,每一层要有明确的职责
- 微服务
- 库
- 模块
- 通信协议
- 接口等的设计
- ……
6. 应用示例1
比如, 我们在网站首页可以登录、注册和退出登录等操作为例:
public interface UserOperate
void login(UserInfo userInfo);
void register(UserInfo userInfo);
void logout(UserInfo userInfo);
public class UserOperateImpl implements UserOperate
@Override
public void login(UserInfo userInfo)
// 用户登录
@Override
public void register(UserInfo userInfo)
// 用户注册
@Override
public void logout(UserInfo userInfo)
// 用户退出
那如果按照单一职责原则拆分, 拆分为如下形式:
public interface Register
void register();
public interface Login
void login();
public interface Logout
void logout();
public class RegisterImpl implements Register
@Override
public void register()
public class LoginImpl implements Login
@Override
public void login()
public class LogoutImpl implements Logout
@Override
public void logout()
具体实践中,上面可以做为参考,是否拆分这种粒度,得结合具体业务来。也可以在项目初期写一个粗略的类,后面根据业务发展再拆分重构,平衡得自己根据业务来把控。
8 应用示例2(结合组合模式)
相同的职责放到一起,不同的职责分解到不同的接口和实现中去,这个是最容易也是最难运用的原则,关键还是要从业务出发,从需求出发,识别出同一种类型的职责。
人类的行为分成了两个接口:生活行为接口、工作行为接口,以及两个实现类。
如果都用一个实现类来承担这两个接口的职责,就会导致代码臃肿,不易维护,如果以后再加上其他行为,例如学习行为接口,将会产生变更风险(这里用到了组合模式)。
-
定义一个行为接口
/** * 行为包括两种: 生活、工作 */ public interface IBehavior
这里面定义了一个空的接口, 行为接口. 具体这个行为接口下面有哪些接口呢? 有生活和工作两方面的行为。
-
定义生活和工作接口, 并且他们都是行为接口的子类
生活行为接口:
public interface LivingBehavior extends IBehavior /** 吃饭 */ void eat(); /** 跑步 */ void running(); /** 睡觉 */ void sleeping();
工作行为接口:
public interface WorkingBehavior extends IBehavior /** 上班 */ void goToWork(); /** 下班 */ void goOffWork(); /** 开会 */ void meeting();
-
上述两个接口的实现类
public class LivingBehaviorImpl implements LivingBehavior @Override public void eat() System.out.println("吃饭"); @Override public void running() System.out.println("跑步"); @Override public void sleeping() System.out.println("睡觉"); public class WorkingBehaviorImpl implements WorkingBehavior @Override public void goToWork() System.out.println("上班"); @Override public void goOffWork() System.out.println("下班"); @Override public void meeting() System.out.println("开会");
-
行为组合的调用
接下来会定义一个行为集合. 不同的用户拥有的行为是不一样 , 有的用户只用生活行为, 有的用户既有生活行为又有工作行为。
我们并不知道具体用户到底会有哪些行为, 所以,通常使用一个集合来接收用户的行为. 用户有哪些行为, 就往里面添加哪些行为。
-
行为组合接口
public interface BehaviorComposer void add(IBehavior behavior);
-
实现组合接口
public class IBehaviorComposerImpl implements BehaviorComposer private List<IBehavior> behaviors = new ArrayList<>(); @Override public void add(IBehavior behavior) System.out.println("添加行为"); behaviors.add(behavior); public void doSomeThing() behaviors.forEach(b-> if(b instanceof LivingBehavior) LivingBehavior li = (LivingBehavior)b; // 处理生活行为 else if(b instanceof WorkingBehavior) WorkingBehavior wb = (WorkingBehavior) b; // 处理工作行为 );
-
-
客户端调用
public static void main(String[] args) // 张三--全职妈妈 (只有生活行为) LivingBehavior zslivingBehavior = new LivingBehaviorImpl(); BehaviorComposer zsBehaviorComposer = new IBehaviorComposerImpl(); zsBehaviorComposer.add(zslivingBehavior); // 李四--职场妈妈 (生活、工作行为都有) LivingBehavior lsLivingBehavior = new LivingBehaviorImpl(); WorkingBehavior lsWorkingBehavior = new WorkingBehaviorImpl(); BehaviorComposer lsBehaviorComposer = new IBehaviorComposerImpl(); lsBehaviorComposer.add(lsLivingBehavior); lsBehaviorComposer.add(lsWorkingBehavior);
示例中体现了单一职责的拆分与组合使用,仅参考。
9. 小结
不管是应用设计原则还是设计模式,最终的目的还是提高代码的可读性、可扩展性、复用性、可维护性等。我们在考虑应用某一个设计原则是否合理的时候,也可以以此作为最终的考量标准。
参考:
《设计模式之美》
《重学 Java 设计模式》
以上是关于「设计模式」六大原则之一:单一职责小结的主要内容,如果未能解决你的问题,请参考以下文章