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

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

• Дайте классу 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 4

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

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

    //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

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

Answer 6

Макер хорошо это накрыл. Кроме того, если вы сделаете это таким образом, то в будущем вы сможете легко перенести некоторые настройки в реальные пользовательские настройки, чтобы они могли настраивать различные части программы. Поскольку все ваши настройки уже выделены в свои собственные классы, это потребует минимальных усилий с вашей стороны.

Answer 7

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

Answer 8

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

Answer 9

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

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

Answer 10

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