Использование пружинных управляемых компонентов в стандартном методе интерфейса?

Question

Предупреждение: я понимаю, что может быть злоупотреблением намерениями за весенними бобами и/или методами интерфейса по умолчанию Java 8. Я ищу конкретную и аргументированную критику того, почему это может быть небезопасным подходом, который я не признаю.

Я определил класс, который дает мне статический доступ к бегущему контексту приложения:

@Component 
public class BeanAccessor implements ApplicationContextAware { 

    private static ApplicationContext applicationContext; 

    public static <T> T getSingleton(Class<T> clazz){ 
     return applicationContext.getBean(clazz); 
    } 

    public static <T> T getSingleton(String beanName, Class<T> clazz){ 
     return applicationContext.getBean(beanName, clazz); 
    } 

    @Override 
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { 
     BeanAccessor.applicationContext = applicationContext; 
    } 

} 

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

Я понимаю, что эта функциональность может быть достигнута путем реализации других классов и сервисов, а не для того, чтобы почувствовать необходимость смешать ее с текущей (по крайней мере, для примера ниже, я на самом деле ничего не делаю с этим) , Это отчасти является «художественным» предпочтением, и я уверен, что продолжу поиск других вариантов использования.

Обратите внимание, что я НЕ пытаюсь сохранить состояние в каждом экземпляре, как описано здесь https://kerflyn.wordpress.com/2012/07/09/java-8-now-you-have-mixins/, и я действительно признаю, что есть опасности в этом.

Вот пример использования:

public interface ClientAware { 

    String TENANT_NAME = "TENANT_NAME"; 

    default ClientDetails clientDetails() { 
     ClientDetailsService service = BeanAccessor.getSingleton(ClientDetailsService.class); 
     return service.loadClientByClientId(SecurityUtil.getClientId()); 
    } 

    default Map<String, Object> clientInfo() { 
     return clientDetails().getAdditionalInformation(); 
    } 

    default String tenant() { 
     return (String) clientInfo().get(TENANT_NAME); 
    } 

} 

И тогда мой фактический класс с помощью интерфейса (и другой интерфейс, который делает подобные вещи, чтобы добавить мета-информацию для ответа):

@RestController 
@RequestMapping("/documents") 
public class Documents implements WrapAware, ClientAware { 

     @Autowired 
     private DocumentService docService; 

     @RequestMapping(method = RequestMethod.GET) 
     public Object byPathAndTenant(@RequestParam("path") String path) { 
      return ok(docService.getDocumentsByPathAndTenant(path, tenant())); 
     } 

} 

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

Answer 1

Есть уже рассмотренные предостережения на пребывание away from statics

В вашем случае, вы можете столкнуться с проблемой, если интерфейс получает ссылки до вашего контекста весны инициализируется. Таким образом, статический ClientDetailsService service будет пустым, что приведет к NPE.

Как правило, с ростом кода вы можете потерять контроль над этим интерфейсом во время запуска приложения.