Тип Безопасного внедрения зависимостей с использованием Java 8.0

Так что я иногда очень скучаю по инъекции зависимостей старой школы. Когда Spring был еще «легковесным», мы с радостью настраивали все наши bean-компоненты в   файле application.xml с конфигурацией xml-компонента « Learn-in-a-day » Spring. Недостатками этого были, конечно, потеря безопасности типа. Я могу вспомнить несколько тестовых случаев, единственная цель которых состояла в том, чтобы загрузить файл конфигурации Spring, и просто посмотреть,  запускается ли  ApplicationContext без ошибок из-за неправильного подключения и правильного разрешения включенных XML-файлов конфигурации bean.

Я могу быть меньшинством, но мне никогда не нравилась конфигурация Spring Schema. Для меня это похоже на конфигурацию для конфигурации.

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

Конфигурация Java Spring делает вещи лучше с безопасностью времени компиляции, но я должен был переосмыслить способ, которым я сделал большую часть моей проводки, поскольку я должен был быть осторожным, как я сделал свою проводку, поскольку я потерял часть ленивого eval, который вы получаете в Контекст Spring, как ваш Java-код, оценивается сразу после   запуска ApplicationContext .

Итак, DI на основе Java — это хорошо, но как мы можем использовать Java 8.0 для его улучшения?

Примените этот лямбда-молот

Right so this is the part of the post that starts applying the new hammer in Java 8.0:Lambdas.

Firstly Lambdas give a type safe way of deferring execution till it’s needed.

So, lets first create a wrapper object called «ObjectDefinition» who’s job it is to define how an object should be created and wired with various values. It works by instantiating the class we want to create and object from (In this case we have a class called «MyObject«). We also give it a list of java.util.function.BiConsumer interfaces which are mapped to a specific value. This list will be used to perform the actual task of setting values on the object.

ObjectDefintion then instantiates the object using normal reflection and then runs though this list of BiConsumer interfaces, passing the the instance of the concrete object and the mapped value.

Assuming we give our ObjectDefinition a fluent DSL we can do the following to define the object by adding the set() method which takes a BiConsumer and the value to set and populates the BiConsumer list as follows:

  MyObject result = new ObjectDefinition() 
    .type(MyObject.class)
    .set((myObject, value)-> myObject.setA(value), "hello world")
    .set((myObject, value)-> myObject.setB(value), "hallo welt")
    .create();

   MyObject result = new ObjectDefinition()
     .type(MyObject.class)
     .set(MyObject::setA, "hello world")
     .set(MyObject::setB, "hallo welt")
     .create();
   String myString = container.get(MyObject.class);  

     Container container = create((builder) -> {
          builder
              .define(MyObject.class)
              .set(MyObject::setA, "hello world");
     }); 

   Container container = create((builder) -> {
      builder.define(String.class)
             .args("hello world");

      builder.define(MyObject.class)
             .inject(MyObject::setA,String.class);
   });
   MyObject myString = container.get(MyObject.class);

    Container container = create((builder) -> {
      builder.define(MyObject.class)
             .set(MyObject::setA,"hello world")
             .initWith(MyObject::start);
    });
    MyObject myString = container.get(MyObject.class);