Welcome!

Java Authors: Yakov Fain, Pat Romanski, Roger Strukhoff, Liz McMillan, Dana Gardner

Related Topics: Java

Java: Article

Java GoF Creational Design Patterns

For cleaner development and easier maintenance

A design pattern is a solution to a recurring problem. Although using patterns this way is well known and has been around for a while, it was only when the GoF wrote their famous book, Design Patterns, on software design patterns, that patterns slowly but surely became an industry standard.

A design pattern is not just object-oriented design, but the communication between these objects. The GoF Creational patterns are a specific subset of these patterns that create objects for you, rather than creating them directly. Why would you want that? It provides cleaner development and easier maintenance for your applications. I'll cover five creation patterns here, and attempt to help you learn and implement them. It's important to not only understand their usage, but also know when to use these patterns. (A basic knowledge of interfaces and abstract classes is assumed as a prerequisite for this article.)

I'll provide at least one simple way to implement each pattern, and at least one scenario in which you might use it. Of course, a complete description is beyond the scope of this article. The other two categories for patterns, as defined by the GoF, are structural and behavioral. We won't discuss these categories here, but instead will keep our focus on creational patterns.

The Factory Pattern
This pattern returns an instance of one of several possible classes based on the data passed. This allows us to introduce new classes without modifying the code substantially. An immediate advantage here is that the instantiation of the class occurs inside the Factory class, which provides more flexibility in code maintenance and development than having to create an object directly in the client of this class.

Example
An example of a Factory pattern is the home interface of an EJB that instantiates a bean based on the data passed to it. Here's another simple hypothetical example. We have a Web site where users are required to enter their phone numbers. To keep our example simple, the phone number can be entered in one of two formats, as shown in Table 1.

Our implementation of the phone classes would look like Listing 1. In this listing we have a base abstract class and two subclasses. Our base class is abstract because we want to enforce instantiation of a subclass only. It's also not necessary to define a constructor for our base class. We have a PhoneFactory class that decides which of the subclasses would be returned based on the argument that is passed to the factory. The returned object from our factory is one of the subclasses, depending on the data passed. Now all a client class needs to do is call the getPhoneNumber() method in the factory class with the phone number as its argument.

The Abstract Factory Pattern
An abstract factory is a factory object that returns one of several related factories. There can't be any simpler definition. This means that instead of returning one subclass, it returns an abstract class that can in turn return a family of its subclasses. Thus both composition and inheritance play equally important roles here. The benefit of using this pattern is that it isolates the concrete subclasses from the client. This pattern should be used when the system is required to be independent of how the components are organized.

Example
We'll expand our future example of phone numbers. If we internationalize our Web page, we can have different phone number types for different countries (see Table 2).

The implementation of the classes is shown in Listing 2. We have more or less a similar structure as before, only a little more complex. Here we have a base abstract class and two subclasses. The subclasses implement the abstract methods of the base class that are capable of returning a PhoneNumber object. We have an InternationalPhoneNumberFactory class that decides which of the subclasses would be returned based on the arguments that are passed to the factory. As before, all a client class needs to do is call the getInternationalPhoneNumber() method in the InternationalPhoneFactory class with the phone number as its argument. The instantiation details and which subclass gets instantiated are hidden from the user. Once we have an international phone number object, we can still have phone numbers with or without spaces for both of the countries. We would call the "with" or "without spaces" method using our previous PhoneFactory class, if required.

The Singleton Pattern
This pattern is used when a class can have only one instance in a system. Think of a Web application when one application-level class is used to track a number of clients. Multiple classes per session are unnecessary; just one for all the clients would suffice. This pattern can be achieved in a number of ways. For example, we can create an exception that will be thrown by a class if it's instantiated more than once. Next we'll have a boolean static variable in our class, because a static variable can be shared among all instances of a class. In the constructor of this class, we'll set this variable the first time it's instantiated. Any other time, since it is already set, the constructor would throw an exception if this variable is already set. This is an excellent strategy. But take care to de-set this variable when the instance is destroyed (in the finalize method). Different JVMs can exhibit different behaviors; using this would ensure we can instantiate an object of this class again after it is destroyed.

If a generic class is needed that only provides static methods, that class can also be declared as final. Using this final-static combination would prohibit any instance creation and allow us to use this class as a whole. Note that this is different from the earlier approach, where we actually created a single object of the class.

Another popular approach to creating Singleton patterns involves having a private constructor and a static method in a class. The private constructor would ensure that an instance can be created only from within the method of the class, which is static. The static method would return an instance and set a boolean variable indicating instance creation. As before, we would de-set this variable in the finalize method as a good coding practice.

These approaches are simple and direct, so I won't provide any example code for them.

The Builder Pattern
The Builder pattern allows a client object to construct a complex object by specifying its type and content only. The way in which objects are assembled can be achieved using a Factory pattern. The factory class used here is called Director, and the actual classes derived are called Builders. This pattern is similar to the abstract factory pattern because both return a family of objects. The difference, however, is that the abstract factory returns a family of related objects while the Builder pattern constructs a complex object one step at a time depending on the data supplied.

Example
I'll attempt to describe a simpler example in which a Builder pattern can be used without providing a Java template for it, as that is beyond the scope of this article (constructing a Builder pattern, Java example would consume 150-200 lines of code). Consider a fast-food restaurant like Burger King where they have a special meal for kids. Irrespective of whether the order is chicken, a hamburger, or something else, the meal always consists of food and a toy. Here the client is the customer, the cashier is the director, and the restaurant crew is the builder. The builder knows how to build the meal, the director knows what to build, but they don't know how to perform each other's tasks. This is a layer of insulation the pattern provides us, that each can be varied without affecting the other.

The Prototype Pattern
This pattern is used when you want to copy an existing instance of a class, instead of creating a new one. Why? Because there might be so much data already in the object that it will take a considerable amount of time to get it again with a new instance. We can use the clone() method of the Object class to create a copy. Of course, the objects that can be cloned need to implement the Cloneable interface.

Imagine a list of value objects that can be obtained from a database that will contain a thousand objects. Each of these value objects would have a lot of information. This data is displayed on a particular Web page and our business need states that the information it contains must be isolated from other database transactions until the user logs out. This information should be displayed in part on different Web pages. This calls for creating a clone. One thing to pay attention to while cloning is that any operation performed on the copied data will also occur on the original data because references to data objects are copied, not the objects themselves. In some cases, this might be unacceptable. In this case, our class would also implement a Serializable interface.

Now we would just write our object out to a stream and reread it, making the two objects completely independent of each other. This again assumes that all the objects contained in this class are themselves serializable. Listing 3 provides the deepClone() method.

Summary
I've discussed five creation patterns here. If you are interested in learning more about patterns, I would recommend reading one of the many books available about design patterns.

References

  • Sangal, P.M. "Using Interfaces and Abstract Classes": java.ittoolbox.com/documents/document.asp?i=3063
  • Java Creation Patterns: www.fluffycat.com/java/patterns.html#creationalpatterns
  • Cooper, J. "Java Design Patterns": www.patterndepot.com/put/8/JavaPatterns.htm

  • More Stories By Puneet Sangal

    Puneet Sangal has been in the Internet technology space for 14 years. He occasionally writes on Internet technology at http://www.inmovi.net/ He can be reached at [email protected]

    Comments (1) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Neil Hornbeck 09/09/04 07:47:15 AM EDT

    The source listing is for a Java card applet, which doesn't seem correct for this article.