Примеры использования шаблонов классов Spring со статическими ссылками

Question

Недавно я наткнулся на код, подобный приведенному ниже.

@Component    
public class Instance {

    private static Instance instance;
    private final Template template;

    public Instance(Template template) {
        this.template = template;
        Instance.instance = this;
    }

    static void someMethod() {
        instance.template.doSomething();
    }
}

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

@Component    
public class Instance {

    private final Template template;

    public Instance(Template template) {
        this.template = template;
    }

    void someMethod() {
        template.doSomething();
    }
}

Мне интересно, каков вариант использования такого шаблона, и если есть какие-либо альтернативы, спасибо!

Answer 1

[править] Просто понял, что статическое поле private и, следовательно, не подвержен влиянию внешнего не Весеннего мира, как я интерпретировал ниже.

В этом случае я не вижу никакой причины делать это. Instance bean является синглтоном благодаря сфере действия Spring "singleton". Таким образом, введение этого статического частного поля не имеет никакого смысла, поэтому то, что вы предлагаете, это, очевидно, правильный подход.

---

[до редактирования]

Я думаю, что это сделано, чтобы выставить Instance Spring bean к другому коду, который не связан с Spring, т.е. может вызывать некоторый не-Spring код Instance.someMethod()

Но, тем не менее, на мой взгляд, это плохая идея, так как она добавляет неинтуитивную ответственность внутри bean-компонента Spring: "Как я могу быть доступен извне Spring?". И что мы будем делать для другого Spring Bean? Добавить этот Spring-anti-pattern ко всем Spring бобам?

Если это необходимо в одном или нескольких местах, я бы предложил использовать @Configurable для Spring-ify класса, где вы можете внедрить зависимость по мере необходимости.

В противном случае, я бы предложил приложению позаботиться об этом взаимодействии "Spring to non-Spring" централизованно и независимо от bean-компонентов: возможно, при запуске скрыть ApplicationContext и извлечь компоненты, внутренне определяющие Spring-agnostic API.