Проверки в методах

218
20 октября 2017, 12:25

У меня часто бывают случаи, когда нужно отправить объект как аргумент к методу, например:

User user = getUser();
insertData(user);

И запись этого объекта в базу:

void insertData(User user){
    if (user != null){
        // записываем в базу
    } else {
        // показываем сообщение
    }
}

И это корректно работает.

Но у меня часто возникает вопрос:

А правильно ли делать проверку на null объекта в методе для записи, а не до того как вызвать этот метод?

То есть,

User user = getUser();
if (user != null){
    insertData(user);
} else {
    // показываем сообщение
}
void insertData(User user){
    // записываем в базу
}

UPD:

Приведя пример записи в базу, я не категорически имел ввиду запись в базу, любой метод. Работа с файлами, просто методы которые решают задачи. Например тот же List<Class> example;

void exampleMethod(List<Example> examList){};

Вопрос: проверку делать до или в методе?

Answer 1

Проверки на валидность до вызова метода обычно не используются, так как это приведет к многократному дублированию кода по валидации перед каждым вызовом метода (из разных мест программы) и вообще сделает код более "грязным". Уместнее проверять корректность данных непосредственно перед их применением (внутри метода).

Что касается именно методов сохранения и тп действий, то валидацию поступивших данных проводят в самом методе, а результат валидации возвращают из метода для вывода всяких сообщений или других действий по решению проблемы.

То есть, в вашем примере, метод проверяет, может ли он записать то, что получил в качестве аргумента и если не может, то не записывает, а из метода возвращает, например, false (или какую то константу, если состояний может быть несколько). Далее, код, который вызывал запись, получает ответ от метода и уже "думает", что с этим делать (например, если пришло false вывести сообщение о неудачной попытке, если true, то подтверждение успешного действия)

но это не универсальное решение для всех случаев и в других действиях такой подход не должен использоваться, то есть в большей части зависит от задачи, решаемой методом. Хорошим примером правильной практики в каждом случае будут анологичные вашим (по выполняемой работе) методы из API

Answer 2

Я бы рекомендовал до, но в самом методе выбрасывать NullPointerException на всякий случай.

В методе вставки в БД не должно быть вывода никаких сообщений и т.п., логика по обработке должна быть в другом месте.

Другой вариант - возвращать из метода о вставке результат операции.

Answer 3

Сложно судить о вашем коде из-за его абстрактности, но в целом так делать неправильно с точки зрения проектирования ПО. Метод, занимающийся вставкой данных в БД не должен ничего знать о пользовательском интерфейсе и о том, как показывать сообщения об ошибках - это не его забота. Такое смешивание логики приводит к связности кода из-за ненужных зависимостей: ваш код работы с данными становится намертво привязан к коду работы с пользовательским интерфейсом из-за того, что в нём используется ненужный ему вывод сообщения. Такой код становится сложнее изменять и тестировать

READ ALSO
Задача о &ldquo;Золотой горе&rdquo; (Java)

Задача о “Золотой горе” (Java)

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

313
Как организировать передачу информации с android-приложения

Как организировать передачу информации с android-приложения

ЗдравствуйтеПишу android-приложение в учебных целях

296
Поиск всех подстрок в двоичном коде

Поиск всех подстрок в двоичном коде

Доброго времени сутокПодскажите примерный план решение следующей задачи: Захар очень любит двоичные последовательности, особенно ему нравится...

356
Пример по generics из Философии Java

Пример по generics из Философии Java

Приветствую всех! Читаю у Брюса Эккеля про дженерики, попался в качестве примера такой код:

232