Статьи

Инъекция Злого Поля против Аннототиомании ™ с Ломбоком

Май 24, 2018

Spring был фреймворком, который изначально принес нам инъекцию зависимостей, например, через совершенно магический  @Autowired или в равной степени магический JEE  @Inject . На этой неделе я наткнулся на  интересную запись в блоге Оливера Гирке , известного разработчика Spring. Оливер утверждает, что «полевая инъекция — это зло». Слушай! Таким образом, внедрение Spring единодушно не поддерживается в Spring / Pivotal?

Оливер хорошо оценивает тестируемость и тот факт, что введенные поля могут быть нулевыми при некоторых обстоятельствах, которые могут не напоминать продуктивную среду. Затем он разрабатывает создание неизменного состояния с помощью конструкторов. Это также рекламируется  JIRM, то Java Неизменный объект Relational Mapper  от  Адама Гента . И очевидно, что неизменность также рекламируется создателями языка Scala, которые систематически отличают изменчивые коллекции от неизменяемых .

Теперь Оливер пытается решить эту проблему с помощью  Project Lombok , инструмента, использующего преимущества  возможностей обработки аннотаций Java, которые  можно увидеть в  этом руководстве . Вот его решение в коде:

@RequiredArgsConstructor(onConstructor=@__(@Inject))
class MyComponent {

  final @NonNull MyCollaborator collaborator;

  public void myBusinessMethod() {
    collaborator.doSomething();
  }
}

Как вы можете догадаться, приведенный выше пример будет генерировать конструктор, принимающий все члены в качестве аргументов, и аннотирует этот конструктор аннотацией JEE @Inject. Теперь это решение, безусловно, работает и помогает избежать проблем, которые могли бы возникнуть, если бы вы сами написали код конструктора.

Но действительно ли это наш «дивный новый мир»? Мы действительно хотели разместить эти аннотации повсюду? Или это только я, чувствуя, что  Annotatiomania ™  злится на нас? Посмотрите этот пример из Code That Made Me Cry, в  котором используется аннотация JPA 2.1 @SqlResultSetMapping. Весь этот код был перемещен из удобочитаемой, обязательной записи в декларативные аннотации.

Решать вещи на уровне языка

Теперь мы можем поспорить, является ли внедрение зависимостей хорошим или склонным к злоупотреблениям. Но эта сторонняя генерация кода обработки аннотаций просто сумасшедшая. Давайте посмотрим, как язык Scala разрешает такие вещи ( как можно увидеть в этой ветке форума ):

class MyComponent @Inject() 
     (collaborator : MyCollaborator) {

  def myBusinessMethod() {
    collaborator.doSomething
  }
}

Теперь это выглядит намного стройнее, не так ли? Мне бы очень хотелось, чтобы у нас тоже была «Scala, хорошие части» на Java. Смешивать конструкторы и неизменяемое состояние с объявлением класса просто потрясающе. Вот как должен быть сделан объектно-ориентированный язык. И это было повторено в  Цейлоне RedHat .

Следите за будущим сообщением в блоге о заимствовании хороших деталей Scala и Цейлона.

34
Share: