就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center寻求指导。
10年前关闭。
我基本上想了解认为在实际代码中使用单一职责原则是合理的人的百分比和 实际上有多少。在 Podcast #38 Joel 谈到这个 OOP 原则在现实世界中是多么无用；并且这进一步证明了像鲍勃叔叔这样的人可能没有编写过非平凡的系统。
我亲自编写过一些软件项目或在一些软件项目中发挥了重要作用，但在我年轻的职业生涯中直到现在才遇到这种模式。我喜欢这个原则的声音，并且真的很想开始使用它。我发现 Joel 在播客中的论点非常薄弱(如果您继续阅读博客评论 here，其他人也会如此)。但是，这有什么真相吗？
社区是怎么想的？
最佳答案
我有一些申请 SOLID 的经验原则和我的经验主要是好的。我也听过播客，听起来 Jeff 和 Joel 都没有尝试过他们谈论的任何事情，时间足够长，无法真正评估其好处。反对的主要论据通常是“您编写更多代码”。如果我看一下我所做的事情，我会多写 10 可能 20% 的代码(通常是接口(interface)定义)，但是因为一切都是高度解耦的，所以它更易于维护。我几乎从来没有遇到过应用程序某个部分的更改会破坏其他部分的情况。所以我必须维护的 20% 的额外代码是为自己买单的。
Jeff 也错过了代码质量这一点。他不认为代码质量对客户有很大好处。他是对的，客户不在乎。客户确实关心快速实现新功能，这就是代码质量的用武之地。我发现，保持尽可能高的代码质量的投资总是在几个月内收回成本。高品质 = 低维护。
我同意他们的观点，就像任何事情一样，你必须对这些事情务实。如果您需要交付某些东西，那么请继续快速而肮脏地完成它。不过事后清理。
关于oop - 在 "real world"中使用单一职责原则，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/488684/