我有一个变长的Java类。当我通过代码质量工具运行它时，我会被标记为类中的行数。
这是一个较低的图层类，由上层使用Spring's @Autowired。该类有许多非静态的私有实例方法。它们不使用任何实例字段，仅适用于方法参数。
我可以安全地将这些方法作为public static移动到某个单独的实用程序类中吗？有什么缺点？
答案 0 :(得分：63)
“错误的”心态。
你不会修改你的课程，因为工具正在抱怨这个或那个。
您希望改善源代码的质量;这些工具可以帮助识别“值得思考的主题”。您将其反馈视为提示;不是“订单”。
因此，您不必担心课程中的“代码行”。相反，您担心此类具有的职责。含义：行号计数本身不是问题 - 但违反Single Responsibility Principle的行为是。
因此：你退后一步，查看你班级到底在做什么。当它显然不止一件事时，你将这些方面提取到其他类中！
含义：如果您确实发现所有这些代码都“属于”该类的责任;然后把它留在那里。不要开始将内部实现细节放入不相关的帮助程序类中;只是因为某些工具会警告你行数。
另一方面，将私有方法转换为静态/包保护的东西将允许您对这些方法进行单元测试。这可能是一个优势。但正如所说：只要我们谈论实施细节，他们应该保持私密;并且它们不应该进行单元测试。
长篇代码：了解并理解“干净代码”的含义;并尝试遵循那里概述的想法。
答案 1 :(得分：4)
方法的划分应该是目的/应用/逻辑（你的名字），而不是技术属性。
长源代码可能可以分成几个小的类，每个类都有自己独立的目的/责任。
答案 2 :(得分：3)
代码质量无法通过行数来衡量。如果您发现类文件日益增长，请确保您的课程遵循单一责任原则。
当你的班级不遵循原则时，将他们分成不同的班级，并将班级变成一个包。
否则，您可以将基类设为abstract class，并将您的util方法设为abstract。有一个子类，它扩展了基类，为基类中的抽象方法提供了实现。
这是一个很好的SO answer on when you could make your methods as static
正如@Zack Jannsen所说，
经常“静止” 当你知道某些东西不会改变时，这是有价值的 实例。如果是这种情况，我会真的考虑“单身 责任原则“，这意味着一个班级应该有一个 责任，因此只有一个改变的理由。我觉得应该 考虑移动“ConvertMpgToKpl（双mpg）”函数，和 类似的方法，给自己的班级。汽车对象的目的是 允许实例化汽车，不提供它们之间的比较。 那些应该是课外的。
尽管static允许您在没有创建对象的情况下访问该方法，但在尝试将该方法设置为静态时始终要记住以下内容
static static 答案 3 :(得分：2)
我经常使用包含静态方法的Utility类，并且发现它非常方便。如果这些方法仅供单个类使用，则可以将Utility类作为静态私有类放在原始类中。但是我发现在很多情况下，一些静态实用程序方法可以被几个类使用，所以在这种情况下我创建一个单独的实用程序类，其中包含一组可以由几个类使用的静态方法。
另外，我非常赞同GhostCat在一般思维方式上的答案。至于班级的规模 - 这可能是一个问题，但通常我不担心这么多。我真正寻找的是你的方法的大小。我喜欢简短和自我解释的方法，从名称和参数名称和顺序以及逻辑开始。如果有大块内部逻辑 - 将其提取到单独的方法中。这使代码更易于阅读和维护。