最新的Yusi主题上线啦!

设计模式之单一职责原则(SRP)

设计模式 lzxianren 1327℃ 0评论

1、 定义

There should never be more than one reason for a class to change. 直译:永远不应该有多于一个原因来改变某个类。 理解:对于一个类而言,应该仅有一个引起它变化的原因。 白话:不同的类具备不同的职责,各司其责。不要一个所谓的“牛”类啥都能干。

2、 核心点

1) 职责:要干嘛? 2) 变化原因:一般都是需求变化引起的,需要考虑需求的变化 注意点: “职责”和“变化原因”是不可度量的,因项目而异,因环境而异。对程序员的素质要求会比较高,能够理解要做什么、要保证多大的变化内可控。

3、 实例

1) 用户有密码设置和删除用户两个方法。从职责的角度来区分,密码设置是对用户信息本身的修改,而删除用户是对用户集合的修改,应该分开。当然我们实际项目中一般设置密码都是PO,或者BO等对象,删除用户一般是service接口,已经对两种进行了区分。

2) 电话有四个方法:拨号、通话、回应、挂机。从职责上来讲,我们可以将其分为两类:连接、数据传输。拨号、回应、挂机属于连接阶段,通话属于数据传输。 考虑连接可能有移动、联通、电信等已有连接方式,还会有大王卡、小王卡等连接方式,而数据传输是相对稳定的,在这种职责和变化原因设定下,良好的设计应该是将其分为两个接口,一个接口负责连接、一个接口负责通话。

小结:对于应用场景的不同理解,决定了你如何看待职责和变化原因。上面例子2中,我们也可以认为四个方法均是电话的职责,那么就没必要再区分两个接口。这也是上面核心点提到的内容。

4、 好处

1)降低了类的复杂性,实现什么职责都有清晰明确的定义;

2)提高可读性(复杂性降低,可读性提高)

3)提高可维护性(可读性提高,可维护性提高)

4)扩展性提高(一个类的单一职责做的好,那么实现不同组合的时候更灵活,扩展性更高)

5、 坏处

1) 单一职责导致类数量增加,项目大的话容易类爆炸

2) 容易过度设计(为了更灵活而把职责划分的过细)

6、 实践

1) 接口最好单一职责

2) 类尽量单一职责

原因:

a) 接口面向行为,行为更多的是职责

b) 类的单一职责,容易导致项目中的类爆炸,开发、维护成本提高

7、 总结

SRP原则作为设计模式的第一原则,首先肯定其是对的,但也是最难把握的。难点就在于如何把握对“职责”的定义,对“变化原因”的考量。具体的实践建议接口单一职责,类尽量单一职责。这样基本可以满足项目中的扩展性、可读性、可维护性的基本要求。 其实现在的微服务可以理解为在应用级别的SRP原则实现。

转载请注明:程序员的自我修养 » 设计模式之单一职责原则(SRP)

喜欢 (1)or分享 (0)
发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址