У меня часто бывают случаи, когда нужно отправить объект как аргумент к методу, например:
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){};
Вопрос: проверку делать до или в методе?
Проверки на валидность до вызова метода обычно не используются, так как это приведет к многократному дублированию кода по валидации перед каждым вызовом метода (из разных мест программы) и вообще сделает код более "грязным". Уместнее проверять корректность данных непосредственно перед их применением (внутри метода).
Что касается именно методов сохранения и тп действий, то валидацию поступивших данных проводят в самом методе, а результат валидации возвращают из метода для вывода всяких сообщений или других действий по решению проблемы.
То есть, в вашем примере, метод проверяет, может ли он записать то, что получил в качестве аргумента и если не может, то не записывает, а из метода возвращает, например, false (или какую то константу, если состояний может быть несколько). Далее, код, который вызывал запись, получает ответ от метода и уже "думает", что с этим делать (например, если пришло false вывести сообщение о неудачной попытке, если true, то подтверждение успешного действия)
но это не универсальное решение для всех случаев и в других действиях такой подход не должен использоваться, то есть в большей части зависит от задачи, решаемой методом. Хорошим примером правильной практики в каждом случае будут анологичные вашим (по выполняемой работе) методы из API
Я бы рекомендовал до, но в самом методе выбрасывать NullPointerException
на всякий случай.
В методе вставки в БД не должно быть вывода никаких сообщений и т.п., логика по обработке должна быть в другом месте.
Другой вариант - возвращать из метода о вставке результат операции.
Сложно судить о вашем коде из-за его абстрактности, но в целом так делать неправильно с точки зрения проектирования ПО. Метод, занимающийся вставкой данных в БД не должен ничего знать о пользовательском интерфейсе и о том, как показывать сообщения об ошибках - это не его забота. Такое смешивание логики приводит к связности кода из-за ненужных зависимостей: ваш код работы с данными становится намертво привязан к коду работы с пользовательским интерфейсом из-за того, что в нём используется ненужный ему вывод сообщения. Такой код становится сложнее изменять и тестировать
Частный дом престарелых в Киеве: комфорт, забота и профессиональный уход
На рисунке изображен треугольник из чиселВычислить наибольшую сумму чисел, которые встречаются на пути, путь начинается с верхней точки...
ЗдравствуйтеПишу android-приложение в учебных целях
Доброго времени сутокПодскажите примерный план решение следующей задачи: Захар очень любит двоичные последовательности, особенно ему нравится...
Приветствую всех! Читаю у Брюса Эккеля про дженерики, попался в качестве примера такой код: