Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>One option would be to inject a <code>Provider&lt;InjectedObject&gt;</code> into your class, as Jesse mentioned:</p> <pre><code>public class MyClass { private final List&lt;InjectedObject&gt; injectedObjects; @Inject public MyClass(Provider&lt;InjectedObject&gt; injectedObjectProvider) { List&lt;InjectedObject&gt; objects = new ArrayList&lt;InjectedObject&gt;(); for (int i = 0; i &lt; 5; i++) { objects.add(injectedObjectProvider.get()); } injectedObjects = Collections.unmodifiableList(objects); } } </code></pre> <p>Doing this can be problematic. If <code>InjectedObject</code> is scoped as <code>@Singleton</code> or <code>@RequestScoped</code>, then each time you call <code>injectedObjectProvider.get()</code> you would get the same reference. Another problem with injecting a <code>Provider</code> to do this is it wouldn't be clear from the API that <code>MyClass</code> depends on multiple instances of InjectedObject. Finally, you've hardcoded in <code>MyClass</code> that it needs to be injected with five instances.</p> <p>It's rare that you will need to inject a <code>Provider</code> into an object. Usually when I do this, it's because the scope of the current object means that it will be longer-lived than the scope of the dependent object (for instance, a <code>@Singleton</code> that needs access to a <code>@RequestScoped</code> object).</p> <p>Instead of injecting a <code>Provider</code>, you can inject a <code>List&lt;InjectedObject&gt;</code> into the constructor, and create a provider method in a Guice module:</p> <pre><code>@Provides MyClass prividesMyClass(Provider&lt;InjectedObject&gt; injectedObjectProvider) { List&lt;InjectedObject&gt; objects = new ArrayList&lt;InjectedObject&gt;(); for (int i = 0; i &lt; 5; i++) { objects.add(injectedObjectProvider.get()); } return new MyClass(objects); } </code></pre> <p>(you could, of course, bind using a <code>TypeLiteral</code>)</p> <p>Why is this better? Even though you are still hard-coding five objects in this code, it isn't hard-coded in <code>MyClass</code>, so clients of <code>MyClass</code> (including the tests for <code>MyClass</code> itself) can choose to construct the object in different ways.</p> <p>If hard-coding this knowledge in a Guice module isn't a good idea, you can instead create an interface that has a more specific contract than <code>Provider</code></p> <pre><code>public interface InjectedObjectRepository { List&lt;InjectedObject&gt; getInjectedObjects(); } </code></pre> <p>Even if you decide that you want <code>MyClass</code> to be responsible for knowing how many instances to create, you might want to create an interface (perhaps named <code>InjectedObjectSupplier</code> so you could document explicitly that you expect a unique instance every time.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload