Знакомимся: Guice - IoC контейнер от Google

Перед любым проектировщиком и/или разработчиком более-менее сложного приложения встает вопрос: "Как уменьшить связность кода?" Собственно, уже давно ни для кого не секрет, что излишняя связность кода приложения - верный путь к увеличению энтропии и сложности поддержки. Особенно, если код криво написан, что, к сожалению, не редкость.

Одним из наиболее популярных (на мой взгляд - лучших) способов уменьшения связности кода является использование паттерна Inversion Of Control (Инверсия управления). Очень часто данный паттерн описывают основным правилом Голливуда: "не звони мне, я сам тебе позвоню". При всей философичности данного описания оно является правильным.

Без философии же данный паттерн описывается следующим образом: взаимодействовать должны не реализации (классы), а абстракции (интерфейсы). Не должно быть такого (без фанатизма конечно же), когда класс зависит от класса. Классы должны зависить от интерфейсов. Возникает вопрос - когда создавать инстансы интерфейсов, ведь понятно, что в рантайме интерфейсов не будет, а будут классы. Так вот, вся прелесть IoC проявляется именно в этом. Вы в одном месте описываете правила, по которым будут созданы объекты для реализации интерфейсов. Остальное за вас сделает используемая IoC-подсистема, в частности - IoC-контейнер.


В мире Java для реализации паттерна IoC очень часто используются специальные средства, именуемые
IoC-контейнерами.

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

Наиболее популярными IoC контейнерами в мире Java являются Spring Framework, HiveMind, Tapestry-IoC (следующая реинкарнация HiveMind), Pico и другие. Но мы сегодня поговорим о Guice - легковесном IoC-контейнере от Google.

Скачать Guice можно как не трудно догадаться с code.google.com. Текущая версия - 1.0. На сайте проекта так-же присутствует ссылка на документацию (в google-doc) но я рекомендую сразу качать pdf - там информация более полная.

Сначала я расскажу о том, что понравилось в Guice, потом кратко покажу основные приемы работы.

Итак, понравилось в Guice:

1. Отсутствие xml-конфигов. Очень напрягает читать портянки конфигов, да еще и разбитые по нескольким файлам (зачастую даже без всякой логики). Очень сильно грешил этим Spring до версии 2.5. В Guice все конфигурируется с помощью аннотаций в Java-коде. Места инъекций (Guice реализует разновидность IoC, которая называется Dependency Injection - инъекция зависимостей) отмечаются специальной аннотацией - @Inject. Можно также делать именованные инъекции и инъекции с помощью своих аннотаций. Далее вся конфигурация реализуется в одном классе вызовом специальных методов.

2. Модульность. С помощью Guice легко построить приложение состоящее из нескольких модулей (я сейчас работаю над реализацией плагинной шины в основе которой лежит Guice). Модуль с точки зрения Guice - отдельный класс, описывающий конфигурацию. Соответственно, можно создавать наборы модулей, заменять одни модули другими и делать все это в рантайме.

3. Широкое использование аннотаций. Можно создавать свои аннотации, аннотации с параметрами, использовать встроенную аннотацию @Named("param") для описания точек расширения. Соответственно, такой код гораздо читабельнее, нежели xml-ная портянка.

4. Инъекцию можно осуществлять на уровне конструктора, метода или непосредственно поля. Причем, в отличие от Spring метод не обязательно должен называться setParam. Он может называться как угодно, но должен быть аннотирован @Inject.

5. Можно использовать свои фабрики для создания объектов, которые будут инъектироваться. В терминах Guice такая фабрика называется провайдером. В частности, в документации по Guice приведен пример создания классов с использованием JNDI.

6. Guice - довольно шустрая штука.

Теперь попробуем сделать что-нибудь простое с помощью Guice. Пусть у нас будет простая задачка - написать приложение, копирующее строку на экран.

Итак, мы напишем класс "читатель", который будет возвращать нам данные. Естественно, он будет не просто так, а реализовывать соответствующий интерфейс. Мы же хотим получать данные по-разному. Точно также напишем класс "писатель", который будет выводить данные на экран. В копировщике же у нас в полном соответствии паттерну IoC будут взаимодействовать не "читатель" с "писателем", а интерфейс "читателя" и интерфейс "писателя". Итак, взглянем на код:

Интерфейс читателя:

package org.google.guice.demo.modules.copier;



/**

 * <p>Created by 07.04.2008

 *   @author Samolisov Pavel

 */

public interface IReader {

    public String read();

}

Примитивный читатель:

package org.google.guice.demo.modules.copier.impl;



import org.google.guice.demo.modules.copier.IReader;



/**

 * <p>Created by 07.04.2008

 *   @author Samolisov Pavel

 */

public class SimpleReader implements IReader {



    public static final String SIMPLE_STRING = "SimpleString";

   

    public String read() {

        return SIMPLE_STRING;

    }   

}

 

Интерфейс писателя:

package org.google.guice.demo.modules.copier;



/**

 * <p>Created by 07.04.2008

 *   @author Samolisov Pavel

 */

public interface IWriter {

    public void write(String data);

}

 

Примитивный писатель:

package org.google.guice.demo.modules.copier.impl;



import org.google.guice.demo.modules.copier.IWriter;



/**

 * <p>Created by 07.04.2008

 *   @author Samolisov Pavel

 */

public class SimpleWriter implements IWriter {



    public void write(String data) {

        System.out.println(data);

    }

}

Интерфейс копировщика:

package org.google.guice.demo.modules.copier;



/**

 * <p>Created by 07.04.2008

 *   @author Samolisov Pavel

 */

public interface ICopier {

    public void copy();

}

Реализация копировщика:

package org.google.guice.demo.modules.copier.impl;



import org.google.guice.demo.modules.copier.ICopier;

import org.google.guice.demo.modules.copier.IReader;

import org.google.guice.demo.modules.copier.IWriter;



import com.google.inject.Inject;



/**

 * <p>Created by 07.04.2008

 *   @author Samolisov Pavel

 */

public class SimpleCopier implements ICopier {



    private IReader reader;

    private IWriter writer;

   

    @Inject

    public SimpleCopier(IReader reader, IWriter writer) {

        this.reader = reader;

        this.writer = writer;

    }

       

    public void copy() {

        writer.write(reader.read());

    }

}

 

В коде копировщика мы видим перед конструктором аннотацию @Inject. Она уведомляет Guice о том, где именно будет происходить инъекция объектов. В данном случае при создании экземпляра класса SimpleCopier ему в конструктор будут переданы построенные читатель и писатель. Если бы мы использовали инъекцию через метод - вызывался бы метод, отмеченный аннотацией @Inject. Выглядело бы это так:

package org.google.guice.demo.modules.copier.impl;



import org.google.guice.demo.modules.copier.ICopier;

import org.google.guice.demo.modules.copier.IReader;

import org.google.guice.demo.modules.copier.IWriter;



import com.google.inject.Inject;



/**

 * <p>Created by 07.04.2008

 *   @author Samolisov Pavel

 */

public class SimpleCopier implements ICopier {



    private IReader reader;

    private IWriter writer;

   

    public void copy() {

        writer.write(reader.read());

    }

   

    @Inject

    public void setReader(IReader reader) {

        this.reader = reader;

    }

   

    @Inject

    public void injectWriter(IWriter writer) {

        this.writer = writer;

    }

}

Как видим - нет никаких ограничений на наименования методов.

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

package org.google.guice.demo.modules.copier;



import org.google.guice.demo.modules.copier.impl.SimpleCopier;

import org.google.guice.demo.modules.copier.impl.SimpleReader;

import org.google.guice.demo.modules.copier.impl.SimpleWriter;



import com.google.inject.AbstractModule;

import com.google.inject.Scopes;



/**

 * <p>Created by 07.04.2008

 *   @author Samolisov Pavel

 */

public class CopyModule extends AbstractModule {



    @Override

    protected void configure() {

        bind(IReader.class)

            .to(SimpleReader.class)

            .in(Scopes.SINGLETON);



        bind(IWriter.class)

            .to(SimpleWriter.class)

            .in(Scopes.SINGLETON);

       

        bind(ICopier.class)

            .to(SimpleCopier.class)

            .in(Scopes.SINGLETON);

    }

}

Ну и наконец - метод main, который все это дело запустит:

package org.google.guice.demo;



import org.google.guice.demo.modules.copier.CopyModule;

import org.google.guice.demo.modules.copier.ICopier;



import com.google.inject.Guice;

import com.google.inject.Injector;



/**

 * <p>Created by 01.04.2008

 *   @author Samolisov Pavel

 */

public class Main {

    public static void main(String[] args) {

        Injector injector = Guice.createInjector(new CopyModule());

        ICopier service = injector.getInstance(ICopier.class);     

       

        service.copy();    

    }

}

 

Все довольно просто: получили модуль и вызвали из него инстанс для нужного интерфейса. Запустили. И ненадо писать много кода для создания классов, от которых зависит данный. Всю работу за нас делает Guice.

Пойдем дальше. Инстанцирование по типу интерфейса - это хорошо, но что делать, когда нам необходимо в разных местах модуля использовать разные реализации интерфейса? Здесь нам на помощь приходят аннотации. Причем, можно использовать стандартную, входящую в Guice аннотацию @Named с параметром. А можно написать свои аннотации. Каждый способ имеет право на жизнь: свои аннотации читать понятнее, в случае же @Named легко забыть какое значение параметра за что отвечает. Опять же, когда много аннотаций - их много надо писать )) В общем, дилема. Я покажу простой пример - пусть писателя в наш копир мы будет инъектировать с помощью своей аннотации @Writer. Напишем сначала саму аннотацию:

package org.google.guice.demo.modules.copier.annotations;



import java.lang.annotation.ElementType;

import java.lang.annotation.Retention;

import java.lang.annotation.RetentionPolicy;

import java.lang.annotation.Target;



import com.google.inject.BindingAnnotation;



/**

 * <p>Created by 07.04.2008

 *   @author Samolisov Pavel

 */



@Retention(RetentionPolicy.RUNTIME)

@Target({ElementType.FIELD, ElementType.PARAMETER})

@BindingAnnotation

public @interface Writer {}

 

Обратите внимание: аннотации при инъекции можно навешивать только на поля или на параметры метода. Это очень важно! Написать то мы можем любую аннотацию, но если повесить ее на метод или, что еще хуже, конструктор - получим эксепшн при работе контейнера.

Ну а реализация аннотации как видим проста - все дело в волшебных пузырьках, ака @BindingAnnotation.

Изменения в коде класса SimpleCopier небольшие:

    @Inject 

    public void injectWriter(@Writer IWriter writer) {

        this.writer = writer;

    }

Самое главное - изменения в конфигурации (класс CopyModule):

bind(IWriter.class)

    .annotatedWith(Writer.class)

    .to(SimpleWriter.class)

    .in(Scopes.SINGLETON);

 

Теперь попробуем все то же самое сделать, используя стандартную для Guice аннотацию @Named

Изменения в SimpleCopier:

    @Inject 

    public void injectWriter(@Named("writer") IWriter writer) {    

        this.writer = writer;

    }

Изменения в CopyModule:

    bind(IWriter.class)

        .annotatedWith(Names.named("writer"))

        .to(SimpleWriter.class)

        .in(Scopes.SINGLETON);

 

Точка расширения, отмеченная аннотацией @Named, попадает в реестр Names. Данный реестр, как мы видим, используется в модуле при создании конфигурации.

Еще одной приятной особенностью Guice является возможность инъекции констант. Для примера - будем передавать читателю строку, которую он должен возвращать, в виде константы. Доработаем читателя:

package org.google.guice.demo.modules.copier.impl;



import org.google.guice.demo.modules.copier.IReader;



import com.google.inject.Inject;

import com.google.inject.name.Named;



/**

 * <p>Created by 07.04.2008

 *   @author Samolisov Pavel

 */

public class SimpleReader implements IReader {

   

    @Inject

    @Named("message")

    private String message;

   

    public String read() {

        return message;

    }   

}

И добавим такие строки в конфигурацию модуля:

bindConstant()

        .annotatedWith(Names.named("message"))

        .to("Hi! I'm annotated message!");

Очень удобная возможность. Позволяет легко выносить константы в файл конфигурации модуля. Вся конфигурация отныне в одном месте.

Думаю, для знакомства достаточно. Буду очень рад, если поделитесь своими впечатлениями от статьи и от Guice в комментариях. Также здорово, если помог кому-то стать на путь истинный. Помните, чем меньше связность кода - тем меньше работы по его поддержке. Используйте современные архитектурные паттерны и будет вам счастье. Всем спасибо за внимание и безбажных вам проектов.

Понравилось сообщение - подпишись на блог