【问题标题】:Where should I place JavaFX constants used for GUI measurements, according to best practices?根据最佳实践,我应该将用于 GUI 测量的 JavaFX 常量放在哪里?
【发布时间】:2017-09-17 13:04:57
【问题描述】:

编辑:我已经看过这个帖子:What is the best way to implement constants in Java?。他们似乎专注于您是否应该使用带有常量的接口。我想知道如果我的常量没有被整个班级使用,我应该把它们放在哪里。


如果我正在设计使用 Shape 包 (javafx.scene.shape.[whatever]) 制作的 GUI,我应该如何放置用于调整它们大小的常量变量?

类范围

我被教导说常量应该总是在类的顶部,这会给我这样的东西:

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

当然,如果有的话,我可能会将我的公共变量放在上面。我可能也会把非常量的私人也放进去。

但是,这意味着我的函数顶部有这些小的常量块。我有两个问题:


1 - 他们经常被忽略

Robert C. Martin 谈到有时程序员会如何在“嘈杂”的 cmets 中发表评论。这些 cmets 太没用了,最终被读者忽略了。我觉得这也适用于用于测量和位置的常量块。


2 - 大多数功能都没有使用它们

这次引用马丁先生的话:

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

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

但是,如果用于度量的常量被类本身而不是它的函数实例化,它们不会破坏这种凝聚力吗?


功能范围

我应该让它们成为这样的函数变量,而不是用类来实例化它们:

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

但是,这样做与我所教的内容背道而驰(但过去我的老师在某些事情上被证明是错误的)。


有些人告诉我创建一个“测量”类并将我所有的常量作为plubic static 变量放在那里。但是我反对这一点,因为这意味着我每次想要添加测量值时都依赖于该类,并且我将拥有一个充满不相关变量的类。


那么,在处理 JavaFX 中用于测量的常量时,最佳实践(或标准)是什么?

【问题讨论】:

标签: java class javafx constants standards


【解决方案1】:

恒定的类结构是最佳实践之一

保持您的命名约定足够可读,这样您就不需要单独的常量类。

始终尝试实现 Keep It S实现 Stupid 和 D不要R重复Y我们自己

相关话题

What is the best way to implement constants in Java?

【讨论】:

  • 是的,我已经看到那个帖子了。我可能没有正确阅读它,但似乎他们更关注为常量创建接口是否是一个好主意的主题(并且共识似乎是“不”)
  • @micka190 还比较了与枚举,性能方面,只是 KISS 和 DRY,没有最佳实践,只有针对您的问题的良好解决方案,便于将来维护
【解决方案2】:

在我看来,一切都与维护和可读性有关。为了确定某件事是否有益,我曾经问自己以下问题:

  1. 此更改会增加可读性吗?为什么?
  2. 我会在未来或其他人做任何进一步的改变吗?如果是这样,我应该怎么做才能使这些更改更容易?

添加太多不必要的常量会增加类的大小,而且会更“噪音”。现在在上面关于 GUI 常量的示例中,我的意见更像是 50-50。我也喜欢用我的 GUI 常量来做这件事,但前提是我的班级很小。因此,如果类体很大,我曾经删除常量并创建一个默认构造函数,将它们初始化为常量而不是全局变量,我这样做的唯一原因是增加可读性,因为有人可以轻松折叠构造函数的代码和噪音消失了。

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

【讨论】:

    猜你喜欢
    • 2015-03-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-05-13
    • 2011-11-09
    • 2012-03-27
    相关资源
    最近更新 更多