我基本上想了解一些人认为在现实世界的代码中使用单一责任原则是合理的，实际上有多少。在
Podcast #38年乔尔谈论这个OOP原则是如何无用的现实世界;此外，这表明Bob叔叔的人们可能不会写出不平凡的系统。
我在几个软件项目中亲自写了或扮演了重要角色，但是在我的年轻职业生涯中，现在才发现了这种模式。我喜欢这个原则的声音，真的很想开始使用它。我发现乔尔在播客中的论据很弱(像其他人一样，如果继续阅读博客评论here)。但是，有什么事实吗？
社区有什么想法？
我有一些应用
SOLID原则的经验，我的经验主要是好的。我也听到播客，听起来好像Jeff和Joel都没有试过任何他们谈论的东西足够长的时间来真正地得到好处。反对的主要论据通常是“你写更多的代码”。如果我看看我做了什么，我会写10个可能20％的代码(通常是接口定义)，但是因为一切都是高度分离的，它更易于维护。我几乎没有任何情况，我的应用程序的一部分的变化会破坏其他部分。所以20％的额外代码我必须维持自己的支付。
杰夫也错过了代码质量的一点。他没有看到代码质量对客户来说是一个很大的好处。他是对的，客户不在乎。客户确实关心快速实现新功能，而且代码质量已经达到了目标。我发现，保持代码质量尽可能高的投资一直在几个月内恢复正常。高质量=低维护。
我同意他们的意见，就像你对这些事情一样务实。如果你需要提供一些东西，然后去做，快速而肮脏。但之后要清理
