Java - является этой хорошей практикой программирования?

Использование специальных классов с магическими числами в качестве статических членов является хорошей практикой Java.

По мере роста программ можно использовать несколько классов настроек, каждый с описательными именами.

Некоторым нравится сгруппировать все эти вещи, магические числа и т. Д. В большом и уродливом XML-файле, который будет прочитан (и понят) во время выполнения. Ваш подход, очевидно, подходит для небольшого проекта (например, общего курса), но подумайте об очевидном преимуществе получения этих настроек из файла XML: вам не нужно перекомпилировать исходный код, чтобы отразить изменения, внесенные в ваши настройки:)

Вы используете то, что некоторые называют «ужасным антипаттерном интерфейса констант», хотя обычно константы находятся в импортированном интерфейсе. У меня нет проблем с этим, особенно после появления статического импорта, но, возможно, кто-то расскажет нам об ужасных бедах. Один из них, кажется, «это не то, для чего предназначены интерфейсы».

Еще большее беспокойство вызывает то, что вы должны запускать свой графический интерфейс в потоке:

    //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);
            }
        });

Как говорили другие, это совершенно хорошая практика, но есть некоторые вещи, которые вы можете сделать, чтобы улучшить код:

• Дайте классу Settings частный запрет. -аргумент конструктор. Это делает невозможным создание экземпляров и делает его намерение хранилища констант более ясным.
• Настройки должны быть final (неизменяемыми), а также статическими .
• Обычно, константы в 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;
}

Macker covered it well. In addition, doing it this way will allow you to, in the future, move some of the settings easily into actual user preferences so they can customize different parts of the program. Since all your settings are already isolated into their own classes, this will require a minimal amount of effort on your part.

Если вы собираетесь использовать статику для своих магических чисел, убедитесь, что они также окончательные, если вы хотите, чтобы они не менялись.

Я думаю, что это может быть хорошей практикой, если настройки вряд ли изменятся и вы документируете взаимосвязь между настройками. Если они могут измениться, то файлы конфигурации и / или аргументы командной строки имеют больше смысла, поскольку они не требуют перекомпиляции.

Изменчивая статика - действительно плохая идея. Придерживайтесь «параметризации сверху».

Его прямо спросили, но в примере кода есть другие проблемы. Вы расширили JFrame (плохая практика), но затем проигнорировали это и создали еще один JFrame для фактического использования. Также необходимо включить шаблон, чтобы всегда получать доступ к компонентам Swing в потоке отправки событий AWT (EDT).

Возможно, вы захотите изучить JSR 296 ( Swing Application Framework ) для работы с настройками / запуском / свойствами графического интерфейса.

Другим решением, не требующим статического импорта, было бы создание полного класса ApplicationSettings с полями, геттерами и сеттерами и передача экземпляра этого класса в конструктор класса. которому нужны параметры. Это позволяет вам сохранить объект конфигурации, который можно легко сохранить или изменить, если вы хотите сохранить новый размер, например, если пользователь изменяет размер окна.