Обработка ошибок Java / исключений с возвращаемым значением - PullRequest
Новая
       18

Обработка ошибок Java / исключений с возвращаемым значением

0 голосов
/ 07 ноября 2018

Итак, мой друг и я программируем Блэкджек на Java, и мы хотели проверить правильность ввода в наших полях ввода (например, ввод только цифр). Поэтому мы сели за его компьютер, и он написал это решение: 

    public static boolean testeTextFieldInt(JTextField textField,  int geld) {
    if (!textField.getText().isEmpty()) {
        try {
            if(Integer.parseInt(textField.getText())>0 && Integer.parseInt(textField.getText())<geld ) {
            return true;    
            }
        } catch (NumberFormatException e) {
            return false;
        }
    }
    return false;
}

Теперь я не согласен с этим решением, потому что ваш код не должен зависеть от ошибки, или я ошибаюсь? поэтому я сел и написал это: 

    public static boolean checkInput(JTextField textField, int spielerGeld, String eingabe) {

    boolean matched = false;

    switch (eingabe) {

    case "num":
        if (!textField.getText().isEmpty() && textField.getText().matches("^[0-9]*$")) {

            int geldinput = Integer.parseInt(textField.getText());

            if (geldinput > 0 && geldinput < spielerGeld) {
                matched = true;
            }
        }
        break;

    case "string":
        if (!textField.getText().isEmpty() && textField.getText().matches("^[a-zA-Z]*$")) {
            matched = true;
        }
        break;

    default:
        break;
    }
    return matched;
}

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

Итак, теперь мой вопрос: какой код «лучше»? и что мы могли бы сделать лучше?

Заранее спасибо!

EDIT1: Так как некоторые уже упоминали, вы говорите, что мой метод не построен по принципу Единой ответственности. Но если разделить на 'checkInputIsnumber' и checkInputIsString ', первое решение (мой друг) все равно останется «лучшим»?

EDIT2: Лучше определено, как в, метод должен быть с низкой цикломатической сложностью, легко читаемым и легко поддерживать в долгосрочной перспективе.

Ответы [ 2 ]

0 голосов
/ 07 ноября 2018

Первый подход намного лучше, чем второй.

  1. Одна ответственность: вам следует избегать создания методов, которые делают больше, чем одно.
  2. Принцип «открыто-закрыто»: ваша «проверка» не является расширяемой. Попробуйте создать Validator интерфейс, а затем реализацию для каждого типа проверки.
  3. Операторы Switch увеличивают цикломатическую сложность и усложняют тестирование.

Кроме того, не используйте textField.getText() везде, вполне возможно, что он будет меняться между вызовами. Присвойте его локальной переменной или, что еще лучше, используйте String в качестве аргумента, а не JText. Как указал Fildor, вы правильно избегаете использования исключений для управления потоком, и действительно лучше иметь одну точку возврата. Сказав это, для простых случаев, когда вы просто анализируете / проверяете и возвращаете, это приемлемо.

0 голосов
/ 07 ноября 2018

Вы должны поставить каждую проверку в одной функции. Через некоторое время ваше «все в одной функции» станет нечитаемым и не поддерживаемым. Также легче изменить чеки, если они находятся в отдельных функциях. Использование try / catch для потока управления не очень хорошая идея. Это дорого во время выполнения. Это не очень хороший стиль, и большинство разработчиков не ожидают потока управления в блоке catch. Исключения составляют исключительные ситуации.

...