Networking with RMI - SCJD Exam with J2SE 5 - page 178

Figure 6-9. The RMI Factory pattern applied to Denny's DVDs
The Factory Pattern—What Is a Factory?
A factory is a software entity that creates other types of software entities. The client makes a
request to a factory for a certain type of object, and out that object comes. Request a different
type, and the factory will create and return the type requested. Of course, the factory needs to
know how to create the requested object; otherwise the factory will complain that it doesn't
understand the request. For instance, you wouldn't request a personal computer from a fac-
tory specializing in producing cars. Likewise, our factory will understand how to create remote
objects. In particular, our factory will make a special type of remote object, a DvdDatabase .
Our factory is not a very robust factory in the sense that we only mass-produce one object
type, a DvdDatabase . One of the most common motivations for implementing an RMI factory is
to reduce the number of remote objects that need to be registered. This allows us to register
the factory only once and gradually evolve and add new remote classes without having to reg-
ister the new classes or even restart the registry. This is a nice by-product of an RMI factory
even though it doesn't apply in our situation.
The RMI factory we implement in Denny's DVDs is an example of a parameterized Fac-
tory pattern, which is a type of creational pattern (i.e., patterns that involve the creation of
objects and/or types; a singleton is another common example of a creational pattern). It is a
variant of the parameterized pattern because we do not actually supply a name or parameter
to the getClient method. It could be written getClient(String class_name_to_create) . How-
ever, since our application only has one remote interface, DvdDatabaseRemote , the type of class
is implied. We do not need to specify. But we could easily modify this method or the factory to
return multiple remote objects.