Mar*_*ers 23 oop single-responsibility-principle solid-principles
在SRP中,"责任"通常被描述为"改变的理由",因此每个类(或对象？)应该只有一个人应该去那里并改变它的原因.
但是,如果你把它变成极端细粒度,你可以说一个对象将两个数字加在一起是一个责任,也是一个可能的改变原因.因此,对象不应包含其他逻辑,因为它会产生另一个改变的原因.
我很好奇是否有人有任何"范围"策略,单一责任原则稍微不那么客观？
Der*_*ley 29
它归结为你正在建模的背景.我已经做了一些大量的写作并介绍了SOLID原则,我在单一责任的讨论中专门解决了你的问题.
以下内容首次出现在2010年1月/ 2月的"Code Magazine"杂志上,并在"SOLID软件开发,一步到位"中在线提供.
单一责任原则规定,一个班级应该有一个,而且只有一个改变的理由.
这起初看起来似乎是违反直觉的.说一个班级应该只有一个理由存在不是更容易吗？实际上,没有任何一个存在的理由可以很容易地被带到一个极端,这将导致更多的伤害而不是好处.如果你把它带到那个极端并构建有一个理由存在的类,那么每个类最终只能有一个方法.即使是最简单的进程,这也会导致大量的类蔓延,导致系统难以理解且难以更改.
一个类应该有一个改变原因的原因,而不是一个存在的理由,是构建系统的业务环境.即使两个概念在逻辑上不同,但是需要它们的业务环境可能需要它们成为同一个.决定课程何时应该改变的关键点不是基于概念的纯粹逻辑分离,而是基于企业对概念的理解.当业务感知和上下文发生变化时,您就有理由更改课程.要了解单个类应该具有哪些职责,您需要首先了解该类应该封装哪个概念以及您希望该概念的实现细节发生更改的位置.
例如,考虑汽车中的发动机.你关心发动机的内部工作吗？您是否关心您有特定尺寸的活塞,凸轮轴,喷油器等？或者,您是否只关心当您上车时发动机是否按预期运行？答案当然完全取决于您需要使用引擎的环境.
如果您是在汽车商店工作的机械师,您可能关心发动机的内部工作原理.您需要了解发动机的具体型号,各种零件尺寸和其他规格.如果您没有此信息,则可能无法正确维护引擎.但是,如果您是一个普通的日常人,只需要从A点到B点的交通,您可能不需要那种级别的信息.各个活塞,火花塞,滑轮,皮带等的概念对您来说几乎毫无意义.您只关心您驾驶的汽车是否有发动机并且运转正常.
引擎示例直接触及单一责任原则的核心.驾驶汽车与维修发动机的环境提供了两种不同的概念,即应该和不应该是一个单一的概念 - 一个改变的原因.在维修发动机的情况下,每个单独的部件都需要分开.您需要将它们编码为单个类,并确保它们符合各自的规范.然而,在驾驶汽车的情况下,发动机是一个单一的概念,不需要进一步细分.在这种情况下,您可能会有一个名为Engine的类.在任何一种情况下,背景都确定了适当的责任分离.