Внедрение сгенерированных классов без написания слишком большого кода конфигурации модуля - PullRequest
Новая
       0

Внедрение сгенерированных классов без написания слишком большого кода конфигурации модуля

2 голосов
/ 19 апреля 2011

Вот ситуация: у меня есть абстрактный класс с конструктором, который принимает логическое значение (которое управляет некоторым поведением кэширования): 

abstract class BaseFoo { protected BaseFoo(boolean cache) {...} }

Все реализации представляют собой сгенерированный исходный код (многие из них десятки).Я хочу создать привязки для всех них автоматически, т.е. без явного ручного кодирования для каждого типа привязки.Я хочу, чтобы сайты инъекций могли указывать либо кэширование, либо отсутствие кэширования (параметр true / false ctor).Например, у меня может быть две инъекции, такие как: 

DependsOnSomeFoos(@Inject @NonCaching AFoo aFoo, @Inject @Caching BFoo bFoo) {...}

(Возможно, это плохая вещь, так как решение о том, кэшировать или нет, может быть лучше в модуле. Но это кажется полезным, учитывая то, что яработая с.)

Тогда возникает вопрос : каков наилучший способ настройки привязок для создания набора сгенерированных типов в униформеКстати, это поддерживает аннотацию привязки, а также параметр конструктора для конкретного класса?

Ранее у меня просто был конструктор по умолчанию для классов реализации, и я просто поместил @ImplementedBy на каждый из сгенерированных интерфейсов.Например: 

// This is all generated source...
@ImplementedBy(AFooImpl.class)
interface AFoo { ... }

class AFooImpl extends BaseFoo implements AFoo {  AFooImpl() { super(true); } }

Но теперь я хочу разрешить отдельным точкам впрыска решать, будет ли истина или ложь передана в BaseFoo, вместо того, чтобы всегда иметь значение по умолчанию, равное истине.Я попытался настроить прослушиватель инъекций (незаметно) для изменения истинного / ложного значения после конструирования, но я не мог понять, как «прослушивать» для диапазона типов, введенных с определенной аннотацией.

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

Я также рассмотрел:

  1. Написание какого-то сканера для обнаружения всех сгенерированных классов и добавления пары привязок для каждого из них, возможно, с помощью Google Reflections.
  2. Создание дополнительных, тривиальных типов «без кэширования» (например, AFoo.NoCache расширяет AFoo), что позволило бы мне вернуться к @ImplementedBy.
  3. Жесткая разводка каждого конкретного типа как кеширующая / не кеширующая, когда она генерируется.

Я не очень хорошо себя чувствую по поводу любой из этих идей.Есть ли лучший способ?

ОБНОВЛЕНИЕ: Спасибо за комментарий и ответ.Я думаю, что генерация небольшого модуля рядом с каждым типом и выписка списка модулей для включения во время выполнения через getResources является победителем.

Тем не менее, после разговора с коллегой, мы могли бы просто увернутьсявопрос, который я поставил, и вместо этого внедрить объект стратегии с методом, подобным boolean shouldCache(Class<? extends BaseFoo> c), в каждый сгенерированный класс.Стратегия может быть реализована поверх конфигурации приложения и будет обеспечивать грубый и детальный контроль.Это приводит к отказу от необходимости варьировать поведение в зависимости от места инъекции.С другой стороны, нам не нужны дополнительные модули.

1 Ответ

1 голос
/ 27 апреля 2011

Есть два дополнительных подхода (в дополнение к тому, что вы упомянули):

  1. Вставьте классы Factory вместо вашего реального класса;то есть ваш код, написанный вручную, в конечном итоге скажет: 

    @Inject
DependsOnSomeFoos(AFoo.Factory aFooFactory, BFoo.Factory bFooFactory) {
  AFoo aFoo = aFooFactory.caching();
  BFoo bFoo = bFooFactory.nonCaching();
  ...
}

    , а ваш сгенерированный код скажет: 

    // In AFoo.java
interface AFoo {
  @ImplementedBy(AFooImpl.Factory.class)
  interface Factory extends FooFactory<AFoo> {}
  // ...
}

// In AFooImpl.java
class AFooImpl extends BaseFoo implements AFoo {
  AFooImpl(boolean caching, StuffNeededByAFIConstructor otherStuff) {
    super(caching);
    // use otherStuff
  }
  // ...
  class Factory implements AFoo.Factory {
    @Inject Provider<StuffNeededByAFIConstructor> provider;
    public AFoo caching() {
      return new AFooImpl(true, provider.get());
    }
    // ...
  }
}

    Конечно, это зависит от интерфейса.

    interface FooFactory<T> {
  T caching();
  T nonCaching();
}

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

...