只需低头努力,剩下的交给时光,时间会公平地帮你处理一切
什么是单一职责原则
单一职责原则(SRP:Single responsibility principle)又称单一功能原则,它规定一个类应该只有一个发生变化的原因
简单来说,就是一个类最好只负责一件事情,只有负责的事情变化了,才会发生变化
如果类的职责过多,就会因需求的变化而频繁改动,这不符合软件设计的原则
职责划分
单一职责的定义很好理解,可是要做起来并没有那么容易,关键就是职责的划分
而划分的依据就是需求,不同的需求、不同的场景可以划分出不同的职责
同一个类在不同的场景下也可能会承担不同的职责
所以,没有完美的设计,只有最适合当下场景的设计
举个例子
场景:某汽车生产厂商,需要设计一个汽车接口,接口里面定义了汽车的属性和行为,各生产线需根据自己的需求实现汽车接口,从而生产自己的汽车
interface Car {
frame();//车架
color();//颜色
tire();//轮胎
start();//启动
stop();//停止
}
Car类有5个方法,都是跟汽车相关的属性和行为,每个生产线都实现Car接口来个性化定制自己的汽车生产
比如根据自己的需求来设计汽车的车架、颜色、轮胎等。
看起来也是合理的,只要需求不变化也不会有大的问题
但谁又能保证需求不会变呢?毕竟我们生在一个多变的世界里
假如我们现在需要给汽车增加播放音乐的功能需要修改接口,我们要给汽车增加一个天窗,也需要修改接口
在需求多变的情况下,每一次需求变更都涉及到接口的改动,有种牵一发而动全身的感觉
很明显Car接口包含了汽车的属性和行为,无论是属性或者行为变化了都会涉及到接口的变更,违背了单一职责原则
我们可以把属性和行为拆成两个接口
Car接口负责汽车的属性
interface Car {
frame();//车架
color();//颜色
tire();//轮胎
}
CarBehavior负责汽车的行为
interface CarBehavior {
start();//启动
stop();//停止
}
这样把汽车的属性和行为拆分开,看起来完美的解决了问题。当有新需求来的时候,涉及到属性改变就修改Car接口,
涉及到行为改变就修改CarBehavior接口,各司其职互不影响,Perfect!
是不是这样就完美了呢?
文章开头就说过,没有完美的设计,只有最适合当下的设计
假如现在工厂要生产可播放音乐的汽车,那很简单嘛,直接在CarBehavior里面增加音乐的功能就行了
interface CarBehavior {
start();//启动
stop();//停止
music();//音乐
}
搞定了,只修改CarBehavior不会影响到Car接口
假如现在工厂要生产摩托车,摩托车只需要最基本的功能,不需要音乐的功能了,但现在CarBehavior里面已经有音乐的功能了,如果使用CarBehavior接口就意味着我生产的摩托车需要预留音乐的功能,但音乐的功能对我没有用啊
这里设计上又出了问题,汽车的行为分为基本行为和个性化行为。
CarBehavior承担了基本行为和个性化行为两种职责,说明我们还需要再分
//汽车的基本行为
interface CarBaseBehavior {
start();//启动
stop();//停止
}
//汽车的个性化行为
interface CarExtBehavior {
music();//音乐
}
看到没有?每一种设计都是跟需求相关的,不同的需求背景下产生的设计是不一样的
总之,单一职责原则是相对当下的需求来说的,没有一个统一的标准,不同需求背景会诞生不同的设计
还是那句话,没有完美的设计,只有最适合当下的设计
单一职责原则误区
1、单一职责就表示接口或类只有一个函数或方法吗?
单一职责原则表示接口或类只承担一个职责,而职责的划分需要根据不同的需求场景来考虑
比如上面的Car接口, 我们有没有必要拆分成CarFrame、CarColor、CarTire这几个接口呢?
其实有没有必要完全取决于当下你的需求,在不同的需求、不同的背景下会诞生不同的设计
2、是不是让自己的应用保持单一职责原则,就会是一个好的设计呢?
单一职责原则是众多设计原则中的一种,它会让你的接口或类只承担单一的职责,一个好的系统架构设计会将多种设计原则结合起来使用,来实现稳定、易扩展的能力
如果感觉对你有些帮忙,请收藏好,你的关注和点赞是对我最大的鼓励!
如果想跟我一起学习,坚信技术改变世界,请关注【Java天堂】公众号,我会定期分享自己的学习成果,第一时间推送给您