Part I: Getting to Know Patterns in Java

Creating Code-128 in Java Part I: Getting to Know Patterns

What are the results You should see the following message:

Not bad; that s what you d expect of most factory objects you usually come across In fact, Java comes stocked with various factories already, such as the XMLReaderFactory class, which lets you build XMLReader objects

try { XMLReader myReader = XMLReaderFactorycreateXMLReader(); } catch (SAXException e) { Systemerrprintln(egetMessage()); }

In Java, XMLReaderFactory is a final class, not designed for inheritance A factory class is a factory class, and that s it It s not designed to be extended But the formal GoF Factory design pattern is somewhat different it offers you more flexibility because before using GoF factories, you re supposed to extend them According to the GoF book, the Factory Method design pattern should Define an interface for creating an object, but let subclasses decide which class to instantiate Factory method lets a class defer instantiation to subclasses The key here is the part that says: let the subclasses decide So far, the factory classes you ve seen here don t let the subclasses decide how to configure the factory unless they simply inherit from it and override it, method by method The GoF Factory Method design pattern gives you more flexibility than the traditional object factory The GoF way of doing things means that you define how factory methods should work and leave it up to subclassers to implement the actual factory Say that the Western division of MegaGigaCo suddenly calls and says that they don t like the FirstFactory class at all they want to be able to create secure connections to the database server, not just standard connections And that means they ve been having to rewrite FirstFactory every time you change it, so that they can create secure database connections That s an issue for the developers every time you update the FirstFactory class, the developers have to rewrite it and adapt it for their own use They re calling to say they want more control over the process Fine, you say, that s what the GoF Factory Method design pattern is really all about delegating control to subclassers To see how this works, I change the way connection objects are created, using the GoF techniques that will make even MegaGigaCo s Western division happy

Still unclear about when to use the GoF Factory Method design pattern Consider the GoF Factory Method pattern when circumstances have gotten decentralized enough so that many programmers who subclass your factory class are overriding it so much that they re changing it substantially

How do you let the subclasses decide which class to instantiate when creating an object factory The way to do that is to define your factory as an abstract class or interface that has to be implemented by the subclasses that actually do the work by creating objects In other words, you at MegaGigaCo headquarters can create the specification for factory objects, and the actual implementation of those factories is up to those who subclass your specification It all starts by creating that factory specification, and I do that with an abstract factory class

public abstract class ConnectionFactory { }

Besides an empty constructor, the important method here is the factory method createConnection I make this method abstract so that any subclasses have to implement it This method takes one argument the type of connection you want to create

public abstract class ConnectionFactory { public ConnectionFactory() { } protected abstract Connection createConnection(String type); }

And that s all you need the specification for an object factory Now the Western division will be happy because they can implement their own concrete factory classes from this abstract factory class