单一责任原则是面向对象编程的规则吗?[关闭]

软件开发中很少有规则是毫无例外的。有些人认为没有地方 转到 但他们错了。

就OOP而言,面向对象没有一个单一的定义,因此根据你问谁,你会得到一套不同的硬原则和软原则、模式和实践。

OOP的经典思想是,消息被发送到其他不透明的对象,对象用自己内部的知识来解释消息,然后执行某种功能。

SRP是一种软件工程原理,可以应用于类、函数或模块的角色。它有助于增强某物的凝聚力,使其能够很好地组合在一起,而不会有无关的部分挂在上面,也不会有多个角色交织在一起,使事情变得复杂。

即使只有一个职责,它仍然可以从单个功能到一组松散相关的功能,这些功能是共同主题的一部分。只要你避免陪审团操纵一个元素来承担它主要不是为之设计的东西的责任,或者做一些其他特设的事情来淡化对象的简单性,那么就违反了你想要的任何原则。

但我发现,与做一些更精细、同样强大的事情相比,更容易纠正SRP。

这些规则都不是法律。它们是更多的指导方针和最佳实践。有时候,遵守“规则”是没有意义的,你需要做最适合你的事情。

不要害怕做你认为正确的事。你可能会想出更新更好的规则。

引用巴博萨船长的话:

“……其次,你必须是海盗才能应用海盗代码,而你不是。 第三,代码更多的是你所说的“指导方针”,而不是实际的规则。..."

引用杰克·斯派洛和;吉布斯。 “我以为你应该遵守规则。” 吉布斯先生:“我们认为它们是更实际的指导方针。”

所以海盗们很清楚这一点。

“规则”可以通过模式运动理解为“力量”

因此,有一股力量试图让类承担单一的责任。(凝聚力)

但也有一股力量试图降低与其他类的耦合。

与所有设计(而不仅仅是代码)一样,答案是它取决于。

啊,我想这与我给出的答案有关。 :)

与大多数规则和法律一样,这些规则也有其相关的潜在动机——如果潜在动机不存在或不适用于你的案件,那么你可以根据自己的需要自由弯曲/打破规则。

话虽如此,SRP本身并不是OOP的规则,但被认为是创建易于扩展和单元可测试的OOP应用程序的最佳实践。

我认为这两个特性在企业应用程序开发中至关重要,因为维护现有应用程序比新开发占用更多时间。

正如许多其他海报所说,所有的规则都是为了被打破。
话虽如此,我确实认为SRP是编写好代码的更重要的规则之一。它并不特定于面向对象编程,但如果类没有单一的职责,OOP的“封装”部分很难正确完成。

毕竟,如何正确而简单地封装一个具有多个职责的类?通常,答案是多个接口和多种语言,这可以提供很大的帮助,但对于你的类的用户来说,它可能在不同的情况下以完全不同的方式应用,这仍然令人困惑。

SRP只是ISP:)的另一种表达。

“P”的意思是“原则”,而不是“规则”:D