Поле с аннотацией @Value и одним методом. Должен ли я сделать их оба stati c? Почему, почему нет? - PullRequest
Новая
       20

Поле с аннотацией @Value и одним методом. Должен ли я сделать их оба stati c? Почему, почему нет?

0 голосов
/ 17 января 2020

У меня есть простой класс построителя URL с методом, который получает значение поля из свойств с помощью @Value аннотации. 

@Getter
@Component
public class UrlBuilder {

    @Value("${url.api}")
    private String apiUrl;
    @Value("${url.auth}")
    private String authUrl;

    public String buildApiUrl(String urlAppendix, Map<String, String> queryParams){
        UriComponentsBuilder builder = UriComponentsBuilder.fromUriString(apiUrl + urlAppendix);
        if (!isEmpty(queryParams)){
            for (String key : queryParams.keySet()){
                builder.queryParam(key, queryParams.get(key));
            }
        }

        return builder.toUriString();
    }
}

Есть ли веская причина сделать метод static и использовать setter Ввод значения в поле stati c? До сих пор мне вводили UrlBuilder через конструктор.

Ответы [ 2 ]

1 голос
/ 17 января 2020
Поля

Stati c и внедрение stati c в целом являются антишаблоном, так как они составляют глобальное общее состояние и создают зависимости порядка и иногда проблемы с безопасностью потоков. (Трудно обеспечить, чтобы вызывающие абоненты никогда не вызывали метод buildApiUrl до того, как произойдет внедрение stati c.) Это особенно верно, если вы планируете использовать метод установки non -stati c для установите это поле stati c, поскольку это означает, что вызов сеттера для одного экземпляра будет также неявно изменять каждый другой экземпляр. Это сбивает с толку API; клиенты будут делать предположения, основанные на общепринятой практике, и не заметят, что их предположения неверны, если они действительно не изучат код.

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

0 голосов
/ 17 января 2020

Я бы никогда не предложил создавать методы stati c в классах Spring Bean, обычно в рамках Spring до создания утилит, я бы не рекомендовал методы stati c.

Когда использовать stati c методы в Java?

  • Код в методе не зависит от создания экземпляра и не использует какую-либо переменную экземпляра.
  • Конкретный фрагмент кода должен использоваться всеми методами экземпляра.
  • Определение метода не должно быть изменено или переопределено. вы пишете служебные классы, которые не должны быть изменены.

Я бы сказал, что вам здесь не нужны никакие итерации или метод утилит, просто используйте пружину MultiValueMap 

MultiValueMap<String, String> map = new LinkedMultiValueMap<>();
    map.add("A", "B");
    map.add("C", "D");

    UriComponentsBuilder builder = UriComponentsBuilder.fromUriString("http://localhost:8080");
    builder.queryParams(map);   //http://localhost:8080?A=B&C=D
...