有一个很好的规则叫做правило 10 - 50 - 500。这意味着理想情况下：
- 包中的类不应超过十个；
- 方法不超过50行；
- 班级不超过500行；
如果你没有强烈违反这条规则，那么，当然，这没有错。
有jdk档案这样的东西src.zip。它有.java-files，您可以在其中看到 -libraries 中类的实现java。java这是当我在 IDE 中单击我的代码中的任何类的名称时 IDE 显示代码的地方。
令我震惊的是，类中有大量代码，一个包中有大量类。有的班级行数接近4000行，一包班级数多到半屏都放不下！
例如，这里java.io.ObjectInputStream是包java.io：
这是为什么？它以前sun和现在是如何解释的oracle？毕竟这样的项目很难支撑，这样的代码有悖于编写干净代码的原则。我尝试着按照这个原理来创建类10 - 50 - 500，但是……在这之后，我已经怀疑这个原理的存在了。难道真实项目中真的没有这样的原理，对初学者来说都是虚构的吗？
PS：我真的希望有关于这个主题的引述和事实，而不仅仅是观点。
因为业务服务应用程序和系统库有着完全不同的质量标准、不同的目的，甚至代码作者的专业水平也不同。
如果您正在编写业务应用程序，那么应用程序的利润及其对不断变化的业务条件的响应速度是首要任务。在一个特定的应用程序中，只是扔掉部分代码或重写，甚至扔掉所有代码并从头开始重写并不丢人。平均而言，业务应用程序是为任务而编写的，任务更改 - 代码更改。此外，此类应用程序是由不同级别的程序员编写的，因此代码可读性在这里也起着重要作用。也就是说，对于业务应用程序来说，重要的是：代码的可读性、快速更改应用程序的能力，而应用程序的平均质量通常远非理想 - 性能下降或错误是常态。
在库中，与业务不同，主要作用是类组合、性能、最少的错误数和向后兼容性。在这种情况下，没有来自业务的需求，只有某种库开发路线图。您不能只是重写所有内容并使其与以前的代码不兼容，如果事实证明您的内置排序适用于正方形，您将无法忍受它，您不能只使虚拟方法非-虚拟或删除一些公共方法或做其他破坏向后兼容性的事情。与业务应用程序不同，您的客户不会单击表单上的按钮，而是编写代码并通过重用您的数据结构将您的库集成到他们的产品中。
因此，从理论上讲，业务应用程序代码应该反映业务流程，并以简单易懂的语言结构来表达。另一方面，库代码应该快速工作并保持向后兼容性，即可读性在那里也很重要，但不是多少，多少效率。
因此，如果您正在编写业务应用程序代码，那么请听听 Bob 大叔的书。但是，如果您编写库，那么您的日常工具就是有关 OOP 和算法的参考书。如果你更深入地研究任何框架的源代码，那么你将看不到任何东西，无论是自写的 hashmams 还是自写的其他算法，它们都会像那样膨胀类，而这一切都是为了性能。好吧，当然，如果业务应用程序是由杂乱无章的团队根据“以更少的钱让我的软件工作更少”的原则编写的，那么先验库需要某种最低（但相当高）的技能水平，因为错误图书馆设计将活得更久，修复起来也更难。