我想知道是直接语句还是对公共静态方法的调用，两者中哪一个更好。
例如，Java Swing中的GridBagConstraints。
通常，您需要设置所有四个变量，如下所示：
GridBagConstraints gc = new GridBagConstraints;
gc.weightx = 1;
gc.weighty = 1;
gc.gridx = 1;
gc.gridy = 1;
这需要许多语句，但让一个有许多重复使用的方法的类成为静态的会更好吗？
考虑PublicMethods.java
PublicMethods.java
public class PublicMethods {
public static void setGC(GridBagConstraints gc, int x, int y) {
gc.gridx = x;
gc.gridy = y;
}
public static void setGCWeight(GridBagConstraints gc, double x, double y) {
gc.weightx = x;
gc.weighty = y;
}
因此，这将处理GridBagConstraints的所有设置。像这样：
PublicMethods.setGCWeight(gc, 1, 1);
PublicMethods.setGC(gc, 1, 1);
根据Java方法调用与使用变量相比，优化可读性会更好，如果是这样，与您可能需要引用该方法的两个语句相比，是否有更多的行可读？
最常见的（在专业Java开发环境中）方法是：
- 为了可读性，可以将第一个解决方案保持原样，将其封装在类内的一个单独的方法调用中
或
- 创建一个类，类似于
GCUtil或ConstraintsUtil，您将在其中保留您建议的静态方法。一段时间后，你可能会有一整套这类CCD_ 6类应该会加快开发，前提是它们设计正确（单一责任，但不是单个方法）
我个人会选择第二种方法，它更干净，可以节省您键入的内容：-）只需确保实际重用它！；-）
在您没有GridBagConstraints的情况下，我不会使用静态方法。原因是你要求读者学习你所使用的其他随机方法调用，而不是直接使用他们对类的知识。这是一个不增加任何价值的间接/抽象层。
我认为这是"简单处理"的领域，因为这些静态方法不一定会减少人为错误，也不一定会以任何实质性的方式使逻辑更加简洁。它们主要提供"句法糖"。它们不会使代码更具确定性/可预测性（提高安全性）。
一般来说，人手不足可能有点风险。它有时真的很有用，有时真的会让你讨厌一年后写的代码。
这在很大程度上取决于你采用这些短手惯例的范围、彻底和一致性。如果你选择用缩写的名字缩写一个标识符，那就没什么不同了。可以说，拥有更紧凑的代码（甚至是水平的）可以提高可读性和可写性，如果您和您的整个团队足够彻底和一致地应用该约定，它开始成为您一眼就能认出、永远不会忘记的东西。如果它是一种奇特的东西，而且只是偶尔使用，它可能会损害所有这些期望的指标，在这种情况下，它的介绍只是为读者提供了另一种需要学习的东西，并且必须不断地记住。一切都是一种走钢丝的平衡行为。
因此，每当你做出这些草率的设计决策时，可能要确保的关键是广泛、彻底、一致地应用它——每天都要使用它们。通过这样做，您可以减少维护代码库的智力开销。如果做不到这一点，人手不够，实际上会增加智力开销。
一个年轻而热情的开发人员往往倾向于专注于短兵相接，减少语法而不是澄清和减少所涉及的逻辑，将两行代码打包成一行代码，例如，实际上没有以任何好的方式简化逻辑。这些年来，随着你越来越适应实际情况，这是一种需要平衡的东西，这些实际情况往往会使代码库更难维护，而这些质量使昨天看起来熟悉的代码今天看起来陌生。程序员的普遍趋势，尤其是处理大规模的代码库，是对自己的创作感到困惑（我想补充一点，就是爱上自己的创作）。这种情况发生的可能性会减少你表面上创造的东西，也会减少你偏离语言习惯用法的可能性。这里的目标是熟悉（不是更少的代码，而是更少的有不熟悉倾向的代码）。
性能
特别是因为这个问题是在性能的背景下提出的，所以从性能的角度来看，在这类实践中，减少函数调用的层次往往更容易。这并不是说要扔掉关于过程编程的书，开始编写调试噩梦般的单片函数，但任何过度的东西都可能开始变成一件坏事。当你将代码库分解成最微小的函数，尤其是在性能最关键的领域，优化可能会变得困难，这与其说是因为函数调用的成本（在很多场景中实际上是免费的），不如说是因为代码的去中心化。在这种情况下，分析热点可能需要您跟踪被调用者的调用者的调用者，甚至需要了解正在做的有意义的工作，这些工作值得在最痴迷的微观层面之外进行分析和优化。
所以我的建议是在这里放松，无论你选择采用什么样的短手，都要确保你的整个团队彻底采用它们。否则，就要寻找方法来减少所涉及的代码量，而不是从语法上，而是更多地通过更高层次的逻辑，并以提高安全性等方式对设计施加约束（例如，用更不灵活的设计来换取更难滥用的更可预测的设计）。如果一个稍微详细一点的语法不容易出错，而且级别也不比简洁的替代语法低很多，那么对它进行欣赏是很有用的，如果你有更多的代码需要4行而不是2行来初始化这个对象，那么就寿命、可维护性甚至优化（不是性能，而是更容易的优化）而言，这可能是更安全的方法。
如果你想以一种更容易应用中央优化的方式来包装东西，这些优化有利于使用它的大量东西，那么你通常想要建立比只允许你一次初始化对象的两个字段更高级别的接口。