CH APT ER 3 T HE HEA RT OF S PR ING: IN VERS IO N O F CO NT ROL in Java

Generator Data Matrix ECC200 in Java CH APT ER 3 T HE HEA RT OF S PR ING: IN VERS IO N O F CO NT ROL

Adding the specific set implementation to the API here would provide very little advantage in return for the extra complexity added to our MailingList class implementation. Of course, there are possible counterarguments even for this scenario, but in the end the choice of when to make a dependency injectable resides with the developer. My advice is to choose whatever approach will make your unit tests easiest to write, and then refactor your code as it proves appropriate. Although this won t give you the correct answer every time, it will at least be easy to change your architecture without needing to substantially rework your unit tests, which will in turn reduce the frustration involved in changing APIs and will keep your code clean and the bug count low.

The framework is not an absolute requirement of dependency injection. Taking our loosely coupled example from Listing 3-2, it is obvious that the injection of the dependencies can be carried out from conventional code. Indeed, as Listing 3-4 shows, this is the sort of code you will have written frequently. Dependency injection is not some strange abstract new technique; it is one of the normal tools of the developer.

final Transport smtp = new SmtpImpl(); final LooselyCoupled lc1 = new LooselyCoupled(smtp); lc1.sendMessage(); final Transport soap = new SoapImpl(); final LooselyCoupled lc2 = new LooselyCoupled(soap); lc2.sendMessage(); In some ways, this is one of the attractive features of dependency injection. You do not have to learn a completely new programming style in order to get the associated advantages; you just have to be a little more disciplined in selecting how and when to apply this technique. Nonetheless, we do in practice use frameworks, so it is reasonable to ask what these offer over and above the benefits available from the kind of hard-coded approach used in Listing 3-4.

The basic container for your Spring application is a BeanFactory. As the name implies, this is a class that is responsible for manufacturing bean instances and then configuring their

dependencies. A Spring bean can be any Java object, although generally we will be referring to standard Java beans. Depending on the bean definition information retained by the bean factory, the beans it instantiates may be created on demand, or may be shared among all clients of the factory. Table 3-1 shows the methods available on classes implementing the BeanFactory interface.

boolean containsBean(String name) String[] getAliases(String name) Object getBean(String name)

Determines whether the factory contains a bean with the given name. Determines the alternative names (aliases) for a bean with the given name. Obtains an instance of the bean with the given name from the factory. This may be a new instance or a shared instance. Obtains an instance of the bean with the given name and type from the factory. This is used by the autowiring feature described in the Autowiring section of this chapter. Determines the type of a bean with a given name. Determines whether the bean definition is a prototype. A prototype is a named set of bean definition information that can be used to abbreviate the configuration of a real bean definition. If a bean definition is a prototype, it cannot be instantiated with a call to getBean(). Determines whether calls to getBean() for the named bean will return a new instance with every call, or a single shared instance (a singleton instance). Determines whether the named bean matches the provided type essentially determines whether a call to getBean(String,Class) would be successful.

Object getBean(String name, Class requiredType)

Class getType(String name) boolean isPrototype(String name)

boolean isSingleton(String name)

boolean isTypeMatch(String name, Class targetType)

The implementation of the factory (how it actually goes about acquiring the instances and configuring their dependencies) is not really our problem. As long as we can acquire a bean factory that materializes suitable beans, we need inquire no further. The limited set of methods available should help to illustrate the fact that a BeanFactory really is a container; the methods provided to you are exclusively about querying the factory about its contents and obtaining items from it. Listing 3-5 shows the instantiation, configuration, and use of a BeanFactory implementation purely from code.