(转)重述——单一职责原则
程序员文章站
2022-03-03 07:56:47
...
单一职责原则(Single Responsibility Principle SRP)
There should never be more than one reason for a class to change.
什么意思呢?
所谓单一职责原则就是一个类只负责一个职责,只有一个引起变化的原因。
如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化会削弱或抑制这个类完成其他职责的能力,这个耦合会脆弱的设计。
软件设计真正要做的许多内容,就是发现职责并把这些职责相互分离;如果能够想到多于一个动机去改变一个类,那么这个类就具有多于一个职责,就应该考虑类的分离。
以调制解调器为例如下图:
从上述类图里面我们发现有四个方法Dial(拨通电话),Hangup(挂电话),Receive(收到信息),Send(发送信息),经过分析不难判断出,实际上Dial(拨通电话)和Hangup(挂电话)是属于连接的范畴,而Receive(收到信息)和Send(发送信息)是属于数据传送的范畴。这里类包括两个职责,显然违反了SRP。
这样做有潜在的隐患,如果要改变连接的方式,势必要修改Modem,而修改Modem类的结果导致凡事依赖Modem类可能都需要修改,这样就需要重新编译和部署,不管数据传输这部分是否需要修改。
因此要重构Modem类,从中抽象出两个接口,一个专门负责连接,另一个专门负责数据传送。依赖Modem类的元素要做相应的细化,根据职责的不同分别依赖不同的接口。如下图:
这样以来,无论单独修改连接部分还是单独修改数据传送部分,都彼此互不影响。
总结单一职责优点:
降低需求变化带来的风险。需求变化是不可避免的,如果单一职责做的好,一个接口修改只对相应的实现类有影响,对其它的接口无影响,这对系统的扩展性和维护性都有很大的帮助。
原文链接:http://www.cnblogs.com/shaosks/archive/2012/02/02/2335478.html
There should never be more than one reason for a class to change.
什么意思呢?
所谓单一职责原则就是一个类只负责一个职责,只有一个引起变化的原因。
如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化会削弱或抑制这个类完成其他职责的能力,这个耦合会脆弱的设计。
软件设计真正要做的许多内容,就是发现职责并把这些职责相互分离;如果能够想到多于一个动机去改变一个类,那么这个类就具有多于一个职责,就应该考虑类的分离。
以调制解调器为例如下图:
从上述类图里面我们发现有四个方法Dial(拨通电话),Hangup(挂电话),Receive(收到信息),Send(发送信息),经过分析不难判断出,实际上Dial(拨通电话)和Hangup(挂电话)是属于连接的范畴,而Receive(收到信息)和Send(发送信息)是属于数据传送的范畴。这里类包括两个职责,显然违反了SRP。
这样做有潜在的隐患,如果要改变连接的方式,势必要修改Modem,而修改Modem类的结果导致凡事依赖Modem类可能都需要修改,这样就需要重新编译和部署,不管数据传输这部分是否需要修改。
因此要重构Modem类,从中抽象出两个接口,一个专门负责连接,另一个专门负责数据传送。依赖Modem类的元素要做相应的细化,根据职责的不同分别依赖不同的接口。如下图:
这样以来,无论单独修改连接部分还是单独修改数据传送部分,都彼此互不影响。
总结单一职责优点:
- 降低类的复杂性,
- 提高可维护性
- 提高可读性。
降低需求变化带来的风险。需求变化是不可避免的,如果单一职责做的好,一个接口修改只对相应的实现类有影响,对其它的接口无影响,这对系统的扩展性和维护性都有很大的帮助。
原文链接:http://www.cnblogs.com/shaosks/archive/2012/02/02/2335478.html
上一篇: (转)Java之美[从菜鸟到高手演变]系列之博文阅读导航
下一篇: 分布式计算自动部署