public static BasicFactory getInstance() {
return instance;
}
public MultiFactory() {
this.orderService = new DefaultOrderServiceImpl();
this.superOrderService = new SuperOrderServiceImpl();
}
public OrderService getOrderService() {
return this.orderService;
}
public OrderService getSuperOrderService() {
return this.superOrderService;
}
}
With this implementation, components that need to access the SuperOrderServiceImpl
implementation class can call the getSuperOrderService() method. However, this approach just negates
the benefit of a factory. Although the components are not coupled by class to a particular implementation,
they are coupled by the method they call on the factory. Another drawback to this approach is that each
new implementation requires a change to the Factory code and a change to the component that needs the
new implementation. Having to add a new method for each new implementation makes this approach
very difficult to configure externally.
Another implementation that tries to solve the problem of transparent support for multiple
implementations requires components that invoke the getOrderService() method to pass in their class to
the getOrderService() method so that the factory can decide, based on the class of the caller, which
implementation to return. This implementation suffers from numerous problems, not least of which is
that it works only with classes, meaning two instances of the same class cannot have different
implementations of the OrderService. You will also find that the implementation of the getOrderService()
method quickly becomes messy when you have many components that need an OrderService
implementation.
A little more elegant approach to this problem is to use a lookup-style approach by having each
component look up the implementation with a key. So, instead of calling getOrderService(), a
component calls getOrderService("someKey"). The drawback of this approach is that in order to maintain
full flexibility, each component must use a separate key so that its implementation can be changed
separately from the others. When the dependent object wants a different implementation of the same
business service, it still needs to change the code to use the key of the corresponding implementation.
The root of this problem lies in the fact that a component actively has to ask for an implementation
class, and to gain full flexibility and ensure that each component can get the appropriate concrete
implementation class that it needs, the request has to be completely unique. This is a problem that is not
solved using the traditional Factory Pattern.
Supporting Multiple Instantiation Modes
Another problem is supporting multiple instantiation modes of an implementation class for different
components. This problem suffers from many of the issues discussed in the preceding section, and
again, the core of this problem is that a component actively has to ask for an implementation class. This
problem is also not solved using the traditional Factory Pattern. Thankfully, Spring solves all of these
problems; we discuss how in the next section.
Search WWH :
