Класс утилит в приложении Spring - использовать статические методы или нет?

Question

Допустим, у меня есть служебный класс DateUtil (см. Ниже). Чтобы использовать этот метод метод вызывающей стороны использует DateUtils.getDateAsString (aDate). Было бы лучше удалить статический модификатор и сделать DateUtil пружинным компонентом (см. DateUtilsBean) и внедрить его в вызывающие классы или просто оставить как есть?

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

public class DateUtils {

    public static String getDateAsString(Date date) {       
        String retValue =  "" // do something here using date parameter
        return retValue;
    }
}

версия Spring Bean

@Component
public class DateUtilsBean {

    public String getDateAsString(Date date) {      
        String retValue =  "" // do something here using date parameter
        return retValue;
    }
}

Answer 1

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

Answer 2

Я согласен с Шоном Патриком Флойдом.

Это мой критерий: если методы класса делают вещи только с параметрами, которые они получают, без внешних зависимостей (база данных, файловая система, конфигурация пользователя, другие объекты / компоненты и т. Д.), То я бы это сделал со статическими методами, обычно в конечном классе с закрытым конструктором.

В противном случае я бы реализовал это с помощью Spring bean.

Итак, в случае, если вы подняли, согласно этому критерию, я бы написал класс со статическими методами.

Привет.

Answer 3

Было бы лучше объявить его как bean-компонент Spring, потому что Spring управляет его жизненным циклом, и вы можете в конечном итоге внедрить зависимости, объединить объект в пул, а также протестировать его надлежащим образом, чтобы не говорить чтобы вы могли использовать его как обычный объект и передать в качестве параметра, переопределить метод в подклассах ... и т. д.

Короче говоря, да, это будет лучший дизайн в большинстве случаев. Тем не менее, в таком простом случае, как разоблачение, это не имеет большого значения.