The no scope (or default scope)

In a sense, no scope fulfills the functions of scope, as it

■ Provides new instances transparently

■ Is managed by the injector

■ Associates a service (key) with some context

Or does it? The first two points are indisputable. However, there arises some difficulty in determining exactly what context it represents. To get a better idea of no scope’s semantics, let’s dissect the example of the toothpaste from earlier. We saw that it took no change in the use of objects to alter their scope. The family.give() sequence looks exactly the same for both singleton and no scope:

family.give("Joanie", injector.getInstance(Toothpaste.class)); family.give("Jackie", injector.getInstance(Toothpaste.class)); family.give("Sachin", injector.getInstance(Toothpaste.class)); Toothpaste Injector Joanie Jackie Sachin Toothpaste Toothpaste << new >> << new >> << new >> Figure 5.2

The injector creates a new Toothpaste

instance for each family member.

Or, expanded using construction by hand (modeled in figure 5.3), the same code can be expressed as follows:

Toothpaste toothpaste = new FluorideToothpaste(); family.give("Joanie", toothpaste);

toothpaste = new FluorideToothpaste(); family.give("Jackie", toothpaste); toothpaste = new FluorideToothpaste(); family.give("Sachin", toothpaste);

In no scope, every reference to Toothpaste implies a new Toothpaste instance. We likened this to the family having three bathrooms, one for each member. However, this is not exactly accurate. For instance, if Sachin brushed his teeth twice,

family.give("Joanie", injector.getInstance(Toothpaste.class)); family.give("Jackie", injector.getInstance(Toothpaste.class));

family.give("Sachin", injector.getInstance(Toothpaste.class)); family.give("Sachin", injector.getInstance(Toothpaste.class));

we would end up with a total of four Toothpaste instances (see figure 5.4).

In our conceptual model, there were only three bathrooms. But in practice there were four tubes of toothpaste. This means that no scope cannot be relied on to adhere to any conceptual context. No scope means that every time an injector looks

Toothpaste Joanie Jackie Sachin Toothpaste << new >> << new >> Toothpaste << new >>

Figure 5.3 Each member of the family receives her own instance of Toothpaste.

Joanie Jackie Sachin

Toothpaste Toothpaste Toothpaste Toothpaste

Figure 5.4 There are now four instances of Toothpaste, one for each use.

for a given key (one bound under no scope), it will construct and wire a new instance. Furthermore, let’s say Sachin took Joanie on vacation and only Jackie was left at home. She would brush her teeth once, as follows:

family.give("Jackie", injector.getInstance(Toothpaste.class)); This would mean only one instance of Tooth-

paste was ever created for the life of the applica- tion. This was exactly what happened with singleton scoping, but this time it was purely acci- dental that it did. Given these two extremes, it is difficult to lay down any kind of strict rules for context with no scope. You could say, perhaps, that no scope is a split-second scope where the context is entirely tied to referents of a key. This would be a reasonable supposition. Contrast sin- gleton and no scope in figure 5.5.

No scope is a very powerful tool for working with injector-managed components. This is partly because it allows a certain amount of flexi-

bility in scaling upward. Dependents that exist for longer times (or in wider scopes) may safely obtain no-scoped objects as they are required. If you recall the Provider pat- tern from chapter 4, there is a close similarity. Granny obtained new instances of an Apple on each use (see listing 5.1, modeled in figure 5.6).

public class Granny {

private Provider<Apple> appleProvider; public void eat() {

appleProvider.get().consume(); appleProvider.get().consume(); }

}

In listing 5.1, the eat() method uses a provider to retrieve new instances, just as we did for Toothpaste, earlier. Here Apple is no scoped.

Guice and Spring differ in nomenclature with regard to the no scope. Spring calls it as the prototype scope, the idea being that a key (and binding) is a kind of template

Listing 5.1 An example of no scope using the Provider pattern

Two new Apples created Granny Provider<Apple> get() Apple obtain Injector

Figure 5.6 Granny obtains instances of Apple (bound to no scope) from a provider. Injector Singleton S A B B No scope

Figure 5.5 Timeline of contexts, contrasting singleton and no scope

(or prototype) for creating new objects. Recall chapter 3, in the section on construc- tor injection and object validity, where no scoping enabled multiple threads to see independent instances of an object (modeled in figure 5.7):

<beans ...>

<bean id="slippery" class="Slippery" scope="prototype"/> <bean id="shady" class="Shady" scope="prototype"/>

<bean id="safe" class="UnsafeObject" init-method="init" scope="prototype"> <property name="slippery" ref="slippery">

<property name="shady" ref="shady"> </bean>

</beans>

This object was actually safe, because any dependents of key safe were guaran- teed to see new, independent instances of UnsafeObject. Like singleton, the name prototype comes from the Gang of Four book, Design Patterns. For the rest of this book I will continue to refer to it as, largely because it is a more descriptive name.

Like Guice, PicoContainer also assumes the no scope if a key is not explicitly bound to some scope:

MutablePicoContainer injector = new DefaultPicoContainer();

injector.addComponent(Toothpaste.class);

family.give("Joanie", injector.getComponent(Toothpaste.class)); family.give("Jackie", injector.getComponent (Toothpaste.class)); ...

There’s almost no difference.

NOTE You will sometimes also hear no scope referred to as the default scope. This is a less descriptive name and typically connotes either Guice or PicoContainer (since they default to no scope).

While no scope doesn’t really lend itself to a context, singleton scope does so quite naturally. Although the design pattern is itself applied in many different ways, we can establish a context quite easily for a singleton.