在"现实世界"中使用单一责任原则

我基本上想要了解那些认为在现实世界代码中使用单一责任原则合理的人的百分比以及实际执行的数量.在播客#38中 Joel谈到了这个OOP原则是如何无用的真实世界; 而且这表明,像鲍勃叔叔这样的人可能没有写过非平凡的系统.

我个人在一些软件项目中写过或发挥过重要作用,但现在才在我年轻的职业生涯中遇到过这种模式.我喜欢这个原则的声音,并且真的想开始使用它.我发现Joel在播客中的论点相当薄弱(如果你继续阅读这里的博客评论那么其他人也是如此).但是,它有什么道理吗？

社区的想法是什么？

我有一些应用SOLID原则的经验,我的经验主要是好的.我也听过播客,听起来杰夫和乔尔都没有尝试过他们谈论的任何事情,足以真正评估好处.反对的主要论点通常是"你编写更多代码".如果我看看我做了什么,我会编写10个或多20%的代码(通常是接口定义),但因为所有内容都是高度分离的,所以它更易于维护.我的应用程序的某个部分的更改几乎没有破坏其他部分的情况.因此,我必须维持的20%额外代码为自己付出代价.

杰夫也错过了关于代码质量的观点.他并不认为代码质量对客户来说是一个巨大的好处.而他是对的,客户并不在乎.客户确实关心快速实现新功能以及代码质量的来源.我发现保持代码质量尽可能高的投资总能在几个月内收回成本.高品质=低维护.

我同意他们的观点,就像你必须对这些事情务实一样.如果你需要提供一些东西,那就继续快速而又脏.但事后要清理干净.

我正在开发一个项目,在一个应该可以被其他人轻松扩展的框架中执行许多不同的,非常复杂的事情.

起初,课程很大,做了很多事情.为了改变这些行为,你必须扩展这些类.这些方法都是虚拟的,并没有改变对象的状态,因此很容易做到这一点.

但是随着系统的发展,框架变得更加清晰,最终会出现一系列整体对象,每个对象都有一些looooong继承链.这也导致了意外的依赖关系 - 一个抽象的方法,它采用类X的集合来生成在基类中定义的对象Y,并指示EVERYBODY必须这样做,即使它对继承树的一半没有任何意义.这也导致大量的类需要数十次单元测试才能使代码覆盖率超过80%,并且复杂性使得您不确定是否正确覆盖了所有内容.很明显,这种设计会使框架变得非常僵硬和不灵活.

因此,我们重新设计了SRP线路上的所有内容.你有你的接口,基类,可能还有一个或多个实现类.每个人都是组成的执行整个过程的关键功能的不同对象.如果您想要更改一个部分,则不会覆盖方法,您将生成另一个扩展必需的接口/基类并以不同方式执行其作业的对象.SRP甚至被归入参数并返回类方法的值.对于需要灵活的系统部分,而不是传递用于生成Y对象的X类集合,创建了一个类来封装Y对象的生成过程.然后,系统中的组件将通过这些生产者,将它们与其他生产者(生产者的责任)结合起来,并最终使用它们来生成Y.这允许创建不同类型的生产者,所有这些生产者都可以完全处理相同,即使他们做了截然不同的事情.此举还大大减少了每个类的代码库,使它们更容易测试.

我会说,作为一个新开发者,将一切都打破到这个水平是非常难的.你几乎不得不写一个大泥球,了解它是如何工作的,然后将它重新设计为几个不同的组件,每个组件都负责整体的一部分.