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

Question

Предположим, что есть приложение, которое создает экземпляр класса Task каждый раз, когда ему нужно обработать некоторые данные. У экземпляра задачи есть некоторые другие сервисы, внедренные в него, но все эти службы и сам объект задачи уникальны в одном экземпляре задачи. Конечно, некоторые глобальные услуги тоже вводятся, но они являются истинными широкими синглонами приложений. Итак, мой вопрос заключается в том, как лучше всего настроить инъекцию этих локальных (или облачных) экземпляров singleton? Я в первую очередь думаю об использовании детского контекста, но как правильно настроить его, это все еще вопрос для меня. Еще одно замечание - использование аннотаций и java-конфигурации.

Answer 1

Решение, которое я, наконец, придумал, требует создания детского контекста.Ключевым моментом является указание другой дочерней конфигурации, чтобы родительский контекст не знал о зависимостях дочерних компонентов. Самое простое решение - создать отдельный java-конфиг с включенным сканированием компонентов и поместить его в выделенный пакет.

@Configuration 
@ComponentScan 
public class TaskConfig {} 

public interface TaskFactory { 
    Task createTask(); 
} 

@Component 
public class TaskFactoryImpl implements TaskFactory { 

    private ApplicationContext parentContext; 

    @Autowired 
    public void setParentContext(ApplicationContext parentContext) { 
     this.parentContext = parentContext; 
    } 

    @Override 
    public Task createTask() { 
     try (AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext()) { 
      context.register(TaskConfig.class); 
      context.setParent(parentContext); 
      context.refresh(); 
      return context.getBean(Task.class); 
     } 
    } 
} 

Answer 2

private static final SingletonObject singleton = new SingletonObject(); 

Частный, чтобы сделать доступным только локально. Статический, чтобы сделать только один. Финал, чтобы остановить его.

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

Answer 3

Если я не ошибаюсь, вы хотите иметь
«Задача» класс двух переменных экземпляра, как
«подзадачи» должен быть только один экземпляр каждого экземпляра Task
«GlobalTask» Должен быть только один экземпляр для каждого приложения/Spring IOC Context
И каждый раз, когда вы создаете экземпляр «Task», вы хотите создать unquie «SubTask» и использовать тот же экземпляр GlobalTask.

, если это правда, я не понимаю, в чем проблема
вы можете достичь, объявляя «Task» и «подзадачи» в качестве прототипа и «GlobalTask», как по умолчанию, как Синглтон, как показано ниже

@Component("Task") 

@ Scope ("прототип") общественного класса Task {

public Task(){ 
    System.out.println("Task Created"); 
} 

@Autowired 
SubTask subTask; 

@Autowired 
GlobalTask globalTask; 

public GlobalTask getGlobalTask() { 
    return globalTask; 
} 

public void setGlobalTask(GlobalTask globalTask) { 
    this.globalTask = globalTask; 
} 

public SubTask getSubTask() { 
    return subTask; 
} 

public void setSubTask(SubTask subTask) { 
    this.subTask = subTask; 
} 

}

@Component("SubTask") 

@Scope ("prototype") public class SubTask { public SubTask() { System.out.println ("SubTask Created"); } public void performTask() { System.out.println («Выполнять задачу»); }}

@Component("GlobalTask") 

общественного класса GlobalTask ​​{

public GlobalTask(){ 
    System.out.println("Global task created"); 
} 

public void performTask(){ 
    System.out.println("Perform Global Task"); 
} 

}

Answer 4

Я думаю custom scopes то, что вы просите. Тем не менее, некоторые слова осторожности: как правило, больная точка, которую вы описываете, получается из чрезмерно плотно связанного дизайна, а не с законной необходимостью вставать на локти во внутренностях контейнера МОК. Возможно, вы являетесь одним из немногих людей, которые действительно имеют эту законную потребность, но гораздо более вероятно, что редизайн решит вашу проблему гораздо более чистым способом.