Хорошо ли поместить System.out.println в отдельный метод? - PullRequest
3 голосов
/ 03 августа 2009

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

Внутри кода я вижу:

ImportUtils.printf("Validation started");

Когда я смотрю на этот метод, он просто вызывает System.out.println:

public static void printf(String s) {
    System.out.println(s);
}

Есть ли в этом преимущество? Может ли это создать проблему в будущем?

Ответы [ 6 ]

15 голосов
/ 03 августа 2009

Вместо создания простой оболочки System.out.println рассмотрите возможность перехода на полноценный API журналирования. Есть много доступных ( Commons Logging , Log4j , SLF4J и многие другие). Их можно легко настроить как простые обертки вокруг консоли, которые полезны для начальной разработки. В дальнейшем их можно изменить, чтобы записывать в файлы, отправлять электронные письма, записывать в базу данных, ... Они также предоставляют контекстную информацию (например, какой класс генерирует журналы), которая очень полезна и трудна для самостоятельного ввода.

6 голосов
/ 03 августа 2009

Типичный пример навязчивой развязки. Совершенно бессмысленно, так как если вы действительно хотите, чтобы System.out писал в другом месте, вы можете использовать System.setOut () . Если вам нужна большая гибкость, не существует нехватки каркасов ведения журналов на выбор.

5 голосов
/ 03 августа 2009

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

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

2 голосов
/ 03 августа 2009

Имя printf для этого метода неверно, поскольку printf означает печать, отформатированную , и этот метод не обладает ни одной из функций, известных printf программистам. 1008 *

С другой стороны, это косвенное обращение может быть полезным, поскольку позволяет в будущем улучшать и обновлять метод ведения журнала без изменения базового кода. Я бы просто не назвал это printf.

1 голос
/ 03 августа 2009

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

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

Так что я бы советовал против этого. Похоже, хорошая идея сделать быстрое изменение от system.out. в журнал или что-то более сложное, но это не поможет в долгосрочной перспективе.

1 голос
/ 03 августа 2009

Не парень по Java, но это похоже на классический случай "вы можете писать на Фортране на любом языке", где этот случай - C.

Единственное преимущество, которое я вижу, - дать C-программисту преимущество в вашем API. Если бы метод назывался «DisplayText» или что-то релевантное, я мог бы увидеть его значение.

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