Spring Dependency Injection в действии

Предположим, что Ваша компания провела маркетинговые исследования и в результате экспертного анализа пришли к выводу, что вашему заказчику в действительности необходим рыцарь. Да, java класс, который представляет рыцаря. После анализа их требований, вы поняли, что они в действительности хотят от вас реализации класса, который представляет Артура, рыцаря круглого стала, который собирается в походы за поиском Святого Грааля.

Да, это странный запрос, но вы ведь уже привыкли к странным запросам маркетингового тима. Поэтому Вы, без доли сомнения, открываете свой любимый IDE и вбиваете класс.

package com.springinaction.chapter01.knight; public class KnightOfTheRoundTable { private String name; private HolyGrailQuest quest; public KnightOfTheRoundTable(String name) { this.name = name; quest = new HolyGrailQuest(); } public HolyGrail embarkOnQuest() throws GrailNotFoundException { return quest.embark(); } }

В этом листинге, имя рыцарю присваивается как параметр конструктора. Его конструктор устанавливает поход рыцаря через создание объекта HolyGrailQuest. Реализация HolyGrailQuest тривиальна:

package com.springinaction.chapter01.knight; public class HolyGrailQuest { public HolyGrailQuest() { } public HolyGrail embark() throws GrailNotFoundException { HolyGrail grail = null; // Look for grail … return grail; } }

Глубоко удовлетворенные своей работой, вы с гордостью комитите код в систему версийности кода. Вы хотите показать его маркетинговой команде, но глубоко убеждены, что чего-то не хватает . Вы не написали ни одного юнит-теста.

Тестирования рыцаря

Юнит-тестирование - важная часть разработки. 

package com.springinaction.chapter01.knight; import junit.framework.TestCase; public class KnightOfTheRoundTableTest extends TestCase { public void testEmbarkOnQuest() throws GrailNotFoundException { KnightOfTheRoundTable knight = new KnightOfTheRoundTable("Bedivere"); HolyGrail grail = knight.embarkOnQuest(); assertNotNull(grail); assertTrue(grail.isHoly()); } }

После написания теста, Вы захотите писать тест для HolyGrailQuest. Но до начала, вы поймете, что KnightOfTheRoundTableTest неявно тестирует HolyGrailQuest.  Также, вы будете сомневаться, сможете ли вы протестировать все непредвиденные ситуации? Что случиться, если метод embark() класса HolyGrailQuest возвратит null? Или что, если он породит GrailNotFoundException?

Кто кого вызывает?

Главная проблема с KnightOfTheRoundTable состоит в том, как он получает HolyGrailTest.  Независимо от того создается ли он новый объект HolyGrail или ссылка получается через JNDI, каждый рыцарь должен иметь свой собственный квест.  Поэтому, нет возможности протестировать класс рыцаря в изоляции.  Каждый раз, как вы тестируете KnightOfTheRoundTable, Вы также будете косвенно тестировать HolylGrailQuest.

Уменьшение связей через интерфейсы

Вся проблема в связях. KnightOfTheRoundTable статически связан с HolyGrailQuest. Они связаны "наручниками" так, что вы не можете иметь KnightOfTheRoundTable без HolyGrailQuest. 

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

Чтобы делать что-либо полезное, классам необходимо знать что-либо друг о друге. Связи обязательны, но должны управляться очень аккуратно.

Общепринятой техникой сокращения связей - это сокрытие деталей реализации за интерфейсами так, что реальный класс с  реализацией может быть быть выгружен без ущерба клиентскому классу. Например, предположим, что Вы создали интерфейс Quest.

package com.springinaction.chapter01.knight; public interface Quest { abstract Object embark() throws QuestFailedException; }

Затем, вы изменяете HolyGrailQuest для реализации этого интерфейса. Также, заметьте, что embark() теперь возвращает Object и кидает QuestFailedException.

package com.springinaction.chapter01.knight; public class HolyGrailQuest implements Quest { public HolyGrailQuest() { } public Object embark() throws QuestFailedException { // Do whatever it means to embark on a quest return new HolyGrail(); } }

Также, следующий метод должен изменен в KnightOfTheRoundTable чтобы стать совместимым с типом Quest.

private Quest quest; … public Object embarkOnQuest() throws QuestFailedException { return quest.embark(); }

Аналогично можно сделать, чтобы KnightOfTheRoundTable реализовывал следующий интерфейс Knight:

public interface Knight { Object embarkOnQuest() throws QuestFailedException; }

Сокрытие реализации класса за интерфейсами - это, безусловно, шаг в правильном направлении. Но есть много разработчиков, которые окажутся в затруднении получить объект Quest. Например, предположим такое возможное изменение KnightOfTheRoundTable:

public class KnightOfTheRoundTable implements Knight { private String name; private Quest quest; public KnightOfTheRoundTable(String name) { this.name = name; quest = new HolyGrailQuest(); } public Object embarkOnQuest() throws QuestFailedException { return quest.embark(); } }

Здесь класс KnightOfTheRoundTable начинает квест с интерфейса Quest. Но рыцарь и дальше получает специфический тип Quest (HolyGrailQuest).  Это не лучше того, что у нас было. KnightOfTheRoundTable  застрял на одних лишь квестах для Holy Grail и никаких других типах.

Брать и отдавать

На этом этапе должен возникнуть следующий вопрос: должен ли рыцарь быть ответственным за получение квеста или кто-то должен "дать" рыцарю квест для старта?

Предположим следующее изменение KnightOfTheRoundTable:

public class KnightOfTheRoundTable implements Knight { private String name; private Quest quest; public KnightOfTheRoundTable(String name) { this.name = name; } public Object embarkOnQuest() throws QuestFailedException { return quest.embark(); } public void setQuest(Quest quest) { this.quest = quest; } }

Заметили изменение?  Теперь рыцарю "дают" квест, а не он сам его "добывает". KnightOfTheRoundTable больше не отвечает за получение квестов вручную.  А из-за того, что он знает о квесте лишь через интерфейс Quest,  Вы можете давать ему любую реализацию Quest.  В другой конфигурации, возможно, могла бы быть реализация RescueDamselQuest и т.д. 

По такому же подобию, тест кейс будет следующий:

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

Присваивание квеста рыцарю:

Теперь, когда у нас есть класс KnightOfTheRoundTable с возможностью приема любого объекта типа Quest, как мы можем задать, какой Quest должен быть передан?

Действие по созданию ассоциаций между компонентами приложения называется проводкой (wiring).  В Spring существует множество способов "связать" (wire) компоненты между собой, но наиболее распространенным вариантом является использование XML. 

Рассмотрим простой конфигурационный файл Spring, knight.xml, который дает квест (HolyGrailQuest) классу KnightOfTheRoundTable.

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> <bean id="quest" class="com.springinaction.chapter01.knight.HolyGrailQuest"></bean> <bean id="knight" class="com.springinaction.chapter01.knight"> <constructor-arg value="Bedivere"/ > <property name="quest" ref="quest" ></property> </constructor-arg></bean> </beans>

Это всего лишь простой метод проводки между бинами.  Теперь, когда мы объявили отношения между рыцарем и квестом, необходимо загрузить XML файл.

Смотрим как это все работает

В Spring приложении, BeanFactory загружает определения бина и связывает их вместе. Поскольку бины в примере с рыцарем объявлены в XML файле, XmlBeanFactory - подходящая фабрика для этого примера. Метод main() использует XmlBeanFactory для загрузки knight.xml  и для получения ссылки на объект Knight.

package com.springinaction.chapter01.knight; import org.springframework.beans.factory.BeanFactory; import org.springframework.beans.factory.xml.XmlBeanFactory; import org.springframework.core.io.FileSystemResource; public class KnightApp { public static void main(String[] args) throws Exception { BeanFactory factory = new XmlBeanFactory(new FileSystemResource( "knight.xml")); Knight knight = (Knight) factory.getBean("knight"); knight.embarkOnQuest(); } }

Как только приложение получит ссылку на объект Knight, он просто вызовет embarkOnQuest() метод для начала приключений рыцаря. Заметьте, что класс ничего не знает про квест, который приготовлен для рыцаря. Единственной сущностью, которая знает какой тип квеста будет дан рыцарю - это knight.xml.

Мораль басни:

Вся эта история малоприменима в реальной жизни, но на сказочных началах демонстрирует принципы использования Dependency Injection.