Вставить класс Util с Google Guice против статических методов?

Question

Мне интересно, будет ли это хороший способ вставлять служебные методы с помощью Google Guice.

Допустим, у нас есть класс утилиты конвертера:

public class UtilClass
{
  public static Result convert(Source src)
  {
    //Do conversion

    return result;
  }
}

Моя идея состоит в том, чтобы использовать guice для внедрения этой Утилиты как Singleton, как это

@Singleton
public class UtilClass
{
  public Result convert(Source src)
  {
    //Do conversion

    return result;
  }
}

Какой способ рекомендуется для Приложения, созданного с помощью guice?

Answer 1

Это зависит от природы вашего convert() метода.

Если это что-то

• простой
• детерминированный (т.е. не зависит от дополнительных параметров)
• не имеет побочных эффектов
• вряд ли изменится
• и т. Д.

Вы можете сохранить его как статический служебный метод.

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

Answer 2

Лично я обычно стараюсь не допустить, чтобы тот факт, что мое приложение подключено с использованием структуры внедрения зависимостей, влияет на решения по проектированию, которые я принимаю для своих классов и т. Д. Хорошая практика проектирования должна диктовать это. В вашем случае может показаться, что ваш служебный класс не зависит от состояния, поэтому кажется разумным кандидатом оставаться статичным.

Независимо от этого, ваш служебный класс не является реализацией какого-либо интерфейса, поэтому код клиента, использующий его, все еще имеет тесно связанную зависимость. При этом трудно понять, что является преимуществом использования DI для внедрения класса утилит вообще по сравнению с простой ссылкой на статический класс непосредственно в коде вашего клиента.

Answer 3

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

Во всяком случае, если UtilClass не имеет состояния, я просто ввожу его , а не как одиночный. Инъекция не-синглтона происходит быстрее, чем инъекция синглтона. Может быть, если вы собираетесь хранить внедренный экземпляр во многих других классах, единственное значение может иметь смысл для экономии места.