Java - 这是一个很好的编程实践吗？

Question

只是想知道以下是否被认为是良好的编程习惯？ 我喜欢尽可能简洁和整洁地保存我的个人源文件，但我想知道更有经验的编码器会想到它。 我特别喜欢Settings.java类的想法，将我的所有“魔数”保存在一个地方。 有没有人建议我如何改进事物？

快乐的编码:-)

class ApplicationLauncher 
{
    public static void main(String[] args) 
    {
        SwingApplication mySwingApplication = new SwingApplication();
    }
}

//////////////

import javax.swing.*;

public class SwingApplication extends JFrame
{
    public SwingApplication()
    {       
        JFrame myJFrame = new JFrame();
        myJFrame.setSize(Settings.frameWidth, Settings.frameHeight);
        myJFrame.setVisible(true);      
    }
}

//////////////

class Settings 
{
    static int frameWidth = 100;
    static int frameHeight = 200;
}

Answer 1

设置类没有任何问题; 但是，在您的示例中，设置在它们应用的框架方面相当暧昧，它们既不是实际设置，而是严格属于SwingApplication类的默认值。

另一件我们无法控制的事情是构造函数如何调用Swing级联到程序的消息泵循环中。

对我来说，永远不会有一个永不返回的构造函数（除非框架被关闭）并且不仅仅是初始化一个对象。

Answer 2

将魔术数字作为静态成员的特殊类是一种很好的Java实践。

随着程序的增长，可以使用多个设置类，每个类都具有描述性名称。

Answer 3

有些人喜欢将所有这些东西，魔术数字等组合在一个大而丑陋的XML文件中，该文件将在运行时被读取（并且有意义）。 您的方法显然适用于小型项目（例如一般课程），但考虑从XML文件获取这些设置的明显优势：您不需要重新编译源代码以反映对您的设置所做的更改:)

Answer 4

你正在使用一些人称为“可怕的常量接口反模式”的东西，尽管通常常量是在导入的接口中。 我没有遇到任何问题，尤其是自静态导入​​问世以来，但也许有人会让我们陷入可怕的祸害。 其中一个似乎是“那不是什么接口”。

更值得关注的是你应该在一个线程中启动你的GUI：

    //Schedule a job for the event-dispatching thread: creating
    //and showing this application's GUI.
    SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                JFrame myJFrame = new JFrame();
                myJFrame.setSize(Settings.frameWidth, Settings.frameHeight);
                myJFrame.setVisible(true);
            }
        });

Answer 5

正如其他人所说，这是一个非常好的做法，但是你可以做一些改进代码的事情：

• 为Settings类提供一个私有的无参数构造函数。 这使得无法实例化并使其作为常量存储库的意图更加清晰。
• 设置应该是final （不可变的）以及static 。
• 通常，Java中的常量是LIKE_THIS而不是likeThis 。
• 如果您使用的是Java 1.5或更高版本，则可以使用import static Settings.FRAME_WIDTH; 在您的类中，可以直接使用FRAME_WIDTH ，而不必编写Settings.FRAME_WIDTH 。

这样就结束了：

class Settings
{
    /** Do not instantiate! */
    private Settings() {}

    static final int FRAME_WIDTH = 100;

    static final int FRAME_HEIGHT = 200;
}

Answer 6

Macker很好地覆盖了它。 此外，通过这种方式，您可以在将来轻松地将某些设置移动到实际的用户首选项中，以便他们可以自定义程序的不同部分。 由于您的所有设置已经被隔离到他们自己的类中，因此您需要花费最少的精力。

Answer 7

我认为只要设置不太可能改变并记录设置之间的关系，这可能是一个很好的做法。 如果这些可能会改变，那么配置文件和/或命令行参数更有意义，因为它们不需要重新编译。

Answer 8

如果你打算使用静力学作为你的幻数，请确保它们也是最终的，如果你的意思是他们不要改变。

Answer 9

可变静力学是一个非常糟糕的主意。 坚持“从上面参数化”。

它被直接询问，但示例代码还有其他问题。 你已经扩展了JFrame （一个不好的做法），但后来忽略了它并创建了另一个实际使用的JFrame 。 此外，您还需要包含样板文件以始终访问AWT事件调度线程（EDT）上的Swing组件。

Answer 10

您可能需要查看JSR 296（ Swing应用程序框架 ）来处理GUI设置/启动/属性。

Answer 11

另一个不需要静态导入的解决方案是创建一个包含字段，getter和setter的完整“ApplicationSettings”类，并将此类的实例传递给需要参数的类的构造函数。 例如，如果要在用户调整窗口大小时保存新大小，则可以保留一个可以轻松保留或修改的配置对象。