根据最佳实践，用于GUI测量的JavaFX常量应该放在哪里？

编辑：我已经看过这个帖子了。他们似乎在关注是否应该使用带有常量的接口。我想知道如果整个类没有使用常数，我应该把它们放在哪里

---

如果我正在设计一个用Shape包（javafx.scene.Shape.[where]）制作的GUI，我应该如何放置用于调整大小的常量变量

类范围 我被教导常数应该总是在课堂上的第一名，这会给我这样的东西：

public class Foo extends Group{
    private final double WIDTH = 100;
    private final double HEIGHT = 100;
    private final double PADDING = 10;
    ...
}

public class foo {
    private void initGUI() {
        final double WIDTH = 100;
        final double HEIGHT = 100;
        final double PADDING = 10;
        ...
    }
}

当然，我可能会把我的公共变量（如果有的话）放在上面。我可能也会把非恒定的私人空间也放进去

然而，这意味着在函数的顶部有这些常量的小斑点。我对此有两个问题：

---

1-他们经常被忽视 Robert C.Martin谈到程序员有时会如何在“嘈杂”的评论中发表评论。这些评论毫无用处，最终被读者忽略了。我觉得这也适用于用于测量和定位的常数块

---

2-大多数函数都没有使用它们 引用马丁先生的话，这一次：

类应该有少量的实例变量。一个类的每个方法都应该操作一个或多个这些变量。一般来说，一个方法处理的变量越多，该方法对其类的内聚性就越强。每个方法使用每个变量的类具有最大的内聚性

他后来说，当然，要达到“最大的内聚力”是相当困难的，只要班级尽可能内聚就可以了

但是，如果由类本身而不是由其函数实例化，那么用于度量的常量不会破坏这种内聚性吗

---

功能范围 与其用类实例化它们，不如让它们成为如下函数变量：

public class Foo extends Group{
    private final double WIDTH = 100;
    private final double HEIGHT = 100;
    private final double PADDING = 10;
    ...
}

public class foo {
    private void initGUI() {
        final double WIDTH = 100;
        final double HEIGHT = 100;
        final double PADDING = 10;
        ...
    }
}

然而，这样做与我所学的背道而驰（但我的老师在过去的一些事情上被证明是错误的）

---

有些人告诉我制作一个“测量”类，并将所有常量作为

plubic static

变量放在那里。但是我反对，因为这意味着每次我想添加一个度量时，我都依赖于这个类，并且我会有一个充满不相关变量的类

---

---

那么，在JavaFX中处理用于测量的常量时，最佳实践（或标准）是什么呢？

常量类结构是最佳实践之一

保持命名约定的可读性，这样就不需要单独的常量类

始终尝试在自己身上执行KeepItSimpleStupid和D

相关线程

---

在我看来，一切都与维护和可读性有关。为了弄清某件事是否有益，我经常问自己以下问题：

这种改变会增加可读性吗？为什么

我会在未来或其他人身上做任何进一步的改变吗？如果是这样的话，我应该怎么做才能使这些更改更容易 添加太多不必要的常量将增加类的大小，这将更像是一种“噪音”。在上面关于GUI常量的示例中，我的观点更像是50-50。我也喜欢用我的GUI常量这样做，但只有在我的类很小的情况下。因此，如果类体很大，我会删除常量并创建一个默认构造函数，将它们初始化为常量而不是全局变量，我这样做的唯一原因是增加可读性，因为有人可以轻松折叠构造函数的代码，噪音消失了

---

最后，我相信最重要的是什么对你和你的团队更有利。即使您在团队中工作时将它们初始化为全局变量或其他内容，您也倾向于适应团队的编程风格选择，而不是您应该适应的“最佳”。

可能的重复没有最佳实践，只有上下文中的良好实践。是的，我已经看到了该线程。我可能没有正确地阅读它，但他们似乎更关注为常量创建接口是否是一个好主意（一致的意见似乎是“否”）@micka190也比较了与enum、性能方面、KISS&DRY、，没有最佳实践，只有很好的解决方案可以解决您的问题，便于将来的维护