Oop 在「；“真实世界”；

我基本上想了解在现实世界的代码中使用单一责任原则合理的人数百分比，以及实际使用的人数。在本书中，Joel谈到OOP原则在现实世界中是多么无用；这进一步证明了像Bob叔叔这样的人很可能没有编写过非平凡的系统

我曾亲自撰写过一些软件项目，或在其中扮演过重要角色，但直到现在我才在年轻的职业生涯中遇到这种模式。我喜欢这个原则的声音，真的很想开始使用它。我在播客中发现乔尔的论点很弱（如果你继续阅读博客评论，其他人也是如此）。但是，这有什么道理吗

---

社区是怎么想的？

我没有读过或听过Joel的评论，因此无法具体评论

---

我认为你必须从目标的角度来看待单一责任原则，而不是严格的要求。与软件开发中的许多事情一样，有一些理想是应该努力实现的，但是，除非您的代码没有金钱上的好处或成本，否则您必须务实地满足客户的需求。

实际上，在OO情况下很难获得真正的SRP。考虑一个存在于一个复杂系统中的类。它可能只有一个面向业务的职责（例如打印报告），但它内部还有许多其他违反纯SRP理念的职责，例如日志记录和异常处理。如果您显著更改了日志记录机制，则可能需要更改printing类的调用

这就是AOP产生的原因。使用它，您无需更改任何内容，只需更改日志记录类即可更改日志记录

出于明显的原因，争取面向业务的SRP是很好的，但是对于足够复杂的系统，在OOP中永远不会得到真正的SRP。AOP，当然，但不是OOP

---

我不知道乔尔的推理是否是这样的，但这就是我处理这个想法的方式。

一般来说，我同意坚实的原则，但你也必须考虑到它们的上下文。如果您正在编写概念证明，那么坚实的原则就不太适用

另一方面，如果你正在开发一种寿命长达数年的产品，那么你最好仔细研究坚实的原则并加以应用。否则，这将使公司在生产率方面损失大量资金

关于乔尔和他的评论，他有一个正确的观点。有时产品需要发货，或者公司倒闭。事情就是这样

---

作为一名开发人员，你的工作是发布产品，但仅仅因为期限很紧并不意味着你的架构很差。像您使用数据集还是业务实体这样的选择是一个简单的决定，两者都有类似的实施工作，但从长远来看，两者之间的新功能开发和维护是激烈的。

我有一些应用原则的经验，我的经验主要是良好的。我也听过播客，听起来杰夫和乔尔都没有尝试过他们谈论的任何东西，足够长的时间来真正评估这些好处。反对的主要论点通常是“你写更多的代码”。如果我看看我所做的，我会多写10%或20%的代码（通常是接口定义），但因为所有东西都是高度解耦的，所以它的可维护性要高得多。我几乎从未遇到过应用程序某个部分的更改会破坏其他部分的情况。因此，我必须维护的20%的额外代码本身是有代价的

Jeff也没有抓住代码质量这一点。他不认为代码质量对客户有很大好处。他是对的，客户不在乎。客户确实关心快速实现新功能，而这正是代码质量的关键所在。我发现保持代码质量尽可能高的投资总是在几个月内得到回报。高质量=低维护

---

我同意他们的观点，就像任何事情一样，你必须在这些事情上务实。如果你需要交付一些东西，那就赶紧去做吧。但事后清理。

我正在一个项目中工作，该项目在一个被认为很容易被其他人扩展的框架中完成许多不同的、极其复杂的事情

起初，班级规模很大，做了很多事情。为了改变这些行为，您必须扩展这些类。这些方法都是虚拟的，并且没有改变对象的状态，所以很容易做到这一点

但是随着系统的发展，越来越清楚的是，这个框架最终将拥有一系列的单片对象，每个对象都有长长的继承链。这也导致了意外的依赖关系——一个抽象方法使用类X的集合来生成基类中定义的对象Y，这要求每个人都必须这样做，即使这对继承树的一半没有意义。这也导致了大量的类，需要数十个单元测试才能使代码覆盖率达到80%以上，而且其复杂性让您无法确定是否正确覆盖了所有内容。很明显，这种设计会导致框架非常僵硬和不灵活

因此，我们按照SRP路线重新设计了一切。您将拥有您的接口、一个基类和一个或多个实现类。每个都由不同的对象组成，这些对象执行整个流程的关键功能。如果您想更改一个部分，而不是重写一个方法，那么您将生成另一个对象，该对象扩展了必需的接口/基类，并以不同的方式执行其工作。SRP甚至包含在类方法的参数和返回值中。对于需要灵活的系统部分，而不是传递用于p的X类集合