Провайдер Singleton против обычного провайдера

Я пытаюсь (в первый раз) создать токен, используя инъекцию зависимостей. У меня проблема с иерархией бриллиантов, где мне нужно добавить подписанный хэш моих данных к фактическим данным.Провайдер Singleton против обычного провайдера

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

Было предложено использовать модель Singleton Provider. Для этого провайдера последующие вызовы get() возвращают один и тот же объект (ссылка). Этот провайдер кэширует результат первого вызова get() и постоянно возвращает его. При инъекции зависимостей я дважды вставляю один и тот же экземпляр этого провайдера, и в результате он возвращает те же данные дважды.

Это заставило меня подумать: есть ли ситуации, когда вы не хотите использовать провайдер Singleton? Если вы ожидаете другого результата, не должен ли каждый новый экземпляр провайдера создаваться каждый раз?

public MyUnderscoreStringSingletonProvider implements Provider<String> 
{ 
    private final Provider<String> mySomeOtherStringProvider; 
    private String myCachedString; 

    public MyUnderscoreStringSingletonProvider( 
     Provider<String> someOtherStringProvider) 
    { 
     mySomeOtherStringProvider = someOtherStringProvider; 
     myCachedString = null; 
    } 

    @Override 
    public String get() 
    { 
     if(myCachedString == null) 
     { 
      myCachedString = create(); 
     } 
     return myCachedString; 
    } 

    private String create() 
    { 
     return "_" + mySomeOtherStringProvider.get(); 
    } 
} 

// ... 

public class SomeCoolService 
{ 
    // ... 

    public Provider<String> injectStringDoubler() 
    { 
     final Provider<String> stringProvider = 
      injectUnderScoreStringProvider(); 
     return new TwoConcatendatedStringsProvider(
      stringProvider, 
      stringProvider); 
     // This would not work if Singleton Provider was not used. 
     // Why should we ever use non-Singleton Providers? 
    } 

    protected Provider<String> injectUnderScoreStringProvider() 
    { 
     return new MyUnderscoreStringSingletonProvider(
      injectMyTimebasedStringProvider() // returns different result 
               // depending 
               // on time. 
      ); 
    } 

    // ... 
}

источник

2013-02-21 studro

Почему вы сказали, что у вас есть проблема иерархии алмазов в Java? –

@SenJacob - это проблема с алмазом в графике инъекции зависимостей. Один и тот же объект нужно использовать дважды, и без провайдера Singleton это будет другой объект, предоставляемый вызовом get() каждый раз. Вопрос в том, почему бы вам не использовать Singleton? Есть ли примеры этого, которые могут быть предоставлены? – studro

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

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

В конечном счете, как и многое другое при разработке программного обеспечения, оно сводится к оценке затрат.

Синглэты просты в использовании и в большинстве случаев обеспечивают ресурсоэффективное решение, однако они не могут использоваться в условиях, не связанных с потоком. например SimpleDateFormat как синглтон обеспечит «случайные» ошибки.

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

источник

2013-03-05 21:38:10 BevynQ

Провайдер Singleton против обычного провайдера

ответ

Смежные вопросы