Получение Guice созданных объектов из тупых объектов данных - PullRequest
Новая
       36

Получение Guice созданных объектов из тупых объектов данных

2 голосов
/ 21 июля 2009

Я сделал решающий шаг и использовал Guice для моего последнего проекта. В целом впечатления хорошие, но я столкнулся с проблемой, которую не могу понять.

Справочная информация. Это приложение Java6, которое принимает команды по сети, анализирует эти команды и затем использует их для изменения некоторых внутренних структур данных. Это симулятор для некоторого оборудования, которое производит наша компания. Изменения, которые я вносю во внутренние структуры данных, соответствуют влиянию команд на реальное оборудование, поэтому последующие запросы структур данных должны отражать состояние оборудования на основе ранее выполненных команд.

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

Единственный способ заставить все это работать - заставить эти объекты команд создавать Guice и передавать структуры данных посредством внедрения. Это кажется действительно неуклюжим и полностью раздувает конструктор объектов данных.

Что я здесь пропустил?

Ответы [ 2 ]

1 голос
/ 21 июля 2009

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

Тем не менее, вы можете использовать провайдеры и @Provides методы для привязки объектов, которые вы создаете сами.

0 голосов
/ 21 июля 2009

Предполагая, что ответ на команду ничем не отличается от ответа на запрос http, я думаю, вы идете по правильному пути.

Обычно используемый шаблон в приложениях http заключается в том, чтобы обернуть логику приложения в объекты с коротким сроком службы, в которые введены как параметры из запроса, так и некоторые внутренние компоненты. Затем вы создаете экземпляр такого объекта и вызываете простой метод без параметров, который делает всю магию.

Может быть, области могут вас как-то вдохновить? Посмотрите в документации и некоторые примеры кода , чтобы прочитать технические детали. В коде это выглядит более менее так. Вот как это может работать в вашем случае: 

class MyRobot {
   Scope myScope;
   Injector i;       

   public void doCommand(Command c) {
      myScope.seed(Key.get(Command.class), 
      i.getInstance(Handler.class).doSomething();
   }
}


class Handler {
   private final Command c;
   @Inject
   public Handler(Command c, Hardware h) {
     this.c = c;
   }

   public boolean doSomething() {
     h.doCommand(c);
     // or c.modifyState(h) if you want c to access internals of h
   }
}

Некоторые люди недовольны этим решением, но я видел это в коде, сильно полагавшемся на Guice в прошлом, по крайней мере, в двух разных проектах.

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

Это немного неловко, и некоторые люди недовольны тем, что вводят ценностные объекты таким образом, но я видел это в прошлом в проектах, которые какое-то время сильно зависели от Guice, и это прекрасно работало.

...