其他分享
首页 > 其他分享> > SRP(单一职责)——没有一只能飞能走的鸟

SRP(单一职责)——没有一只能飞能走的鸟

作者:互联网

单一职责原则(SRP:Single responsibility principle)又称单一功能原则。它规定一个类应该只有一个发生变化的原因。

一、起因

编码中,需要创建一只小鸟,既能飞,用能走。
我写的时候,我会定义两个接口,IFly,IWalk,然后实现他们。
image
然后,外部模块需要用到我的“鸟”,进行操作。这个时候,有同事过来了,说“按照SRP,你这个鸟有问题”
难道我要提供两只鸟:一只FlyBird,一只WalkBird?

二、问题

“一个类应该只有一个发生变化的原因”
在《敏捷软件开发:原则、模式与实践》90页,清晰的写着“我们把两个职责都耦合进了ModemImplementation类中,这不是所希望的,但或许是必要的,常常由于一些和硬件或者操作系统的细节有关的原因,迫使我们这样去处理。我们可以把它看做一个有缺陷的类,所有的依赖关系都是从它出发,谁也不需要依赖它。除了Main以为,谁也不需要知道它的存在。因此我们已经把丑陋的部分隐藏起来。”
image

三、思考

比如当前外部有一个大的舞台场景,里面有“鸟”,“云”,“天空”,
伪代码:

class Scene{
bird:Brid;
cloud:Cloud;
sky:Sky;
}

按照 “标准srp”,我提供的是一个“飞,走,职责揉进bird”的类,是“丑陋的鸟”。
那怎样写出一只“不丑陋的鸟”呢?
答案是,没有这样的一只鸟。因为你的鸟需要“飞,走”。

在书中提到的“main”,是我们现在用到的场景么?个人觉得,不是!!!
“main”应该是指最外层的调用者,而不是中间层的调用者。最外层只能是 文档类(入口类)。
对于外界来说,我的鸟,能飞,能走,已经是一个独立的组件了,不能将两者分离。
如果我创建两只鸟,FlyB,WalkB,那么,这鸟如果再中间层被使用,每次都要在两只鸟中艰难选择。

当然,调用者想用 ISP,这个要看他的需求了。

四、结论

个人觉得,我最开始的设计没有问题。SRP对于最底层的组件,可以适用;但是对于中间各层的组件,就会出现结构过于分散,职责过于细致,适用过于繁杂。

标签:职责,调用者,一只,SRP,组件,丑陋,飞能
来源: https://www.cnblogs.com/wyy5552/p/14766805.html