June 22, 2018
Hot Topics:

Build and Command Objects-Using Design Patterns

  • June 15, 2006
  • By Vlad Kofman
  • Send Email »
  • More Articles »

"A software design pattern, the Builder pattern is used to enable the creation of a variety of complex objects from one source object. The source object may consist of a variety of parts that contribute individually to the creation of each complex object through a set of common interface calls of the Abstract Builder class."

"In computer programming, Command Pattern is a Design Pattern: a standard solution to a common problem in software design. The Command Pattern encapsulates invocation and allows code that causes actions to be initiated to be separated from code that performs those actions."

Wikipedia online

In the software development world, many projects involve complex architectures, multi-tier frameworks. and extensive planning. Yet, simple design patterns are some how overlooked. The design patterns that simplify overall flow of the information in the project or emphasize logic reuse will achieve wonders if implemented correctly. Many projects are designed to include enterprise scale patterns such as Model View Controller (MVC) or Data Access Object (DAO), but simple patterns such as Singleton or Visitor may never even be considered.

It is as if project architects think that some "buzzword" patterns are enterprise material and others are not worth considering. The benefit of the less known, but equally useful, patterns is sometimes greater than from the more popular ones.

I am not saying that all design patterns should be used in a project, or even considered. All patterns have a specific problem space that they address. However, I do believe that careful planning of the design phase of an enterprise-scale application should include several fine-grained patterns that deal with logic, data, or its flow.

This article will deal with two often overlooked or underused design patterns: one creational Builder pattern and one a behavioral Command pattern. I will explore their application in the software architecture process, describe the purpose of these patterns, and show how they can be used in real-world Java projects.

Builder Pattern

Builder is one of the "easier-to-understand-and-difficult-to-find-use-for" patterns. But, with some practice, even novice architects can begin to reuse this pattern. It is a creational pattern; that places it in the same category as a "factory" or "singleton," but its intent as stated in the original "gang of four" book is to "separate the construction of a complex object from its representation so that the same construction process can create different representations."

What this really means is that this pattern is very useful at daisy-chaining some actions to take one object and transform it into another, to change its properties or appearance. Applications for this little concept are infinite, from parsers of data to modification of Swing GUI objects models.

Imagine a situation, in an enterprise application, where data is coming in real time and needs to be processed, formatted, and displayed. A stream of market data, for example, would have ticket symbols, "bid" and "ask" prices, and volume information. Every part of the incoming data represents a different number or character value and needs to be parsed or formatted accordingly. Monetary data needs a "$" in front and ticker symbol needs to be uppercased, for instance.

Builder pattern takes initial data (or object) and transforms it by a set of methods defined in a public interface. The concrete classes that implement "builder" interface are required to accept the same type of object and perform the same API call.

The specific business rules that those concrete builders follow must be implemented in the public methods exposed by the interface.

Here is a sample interface that has one method "build" and takes an Object type and returns an Object type. In this example, I'm using a very generic Object and assuming that a Sting type will be passed in, but any types could be used.

public interface Builder {
   Object build(Object o);

A concrete class would have its logic implemented in the "build" method it overwrites:

public class SimpleBuilder implements Builder {
   public Object build(Object o) {
      if (o instanceof String){
         o = ((String)o).toUpperCase();
      return o;

Therefore, any feasible operation can be done on the object of the correct type. As I mentioned, the powerful feature of this pattern is that several concrete builders can be daisy chained together. A complex concrete builder can take several concrete builder objects, put them in a list, and traverse through them. Each Builder in the list will execute a "build" action on the passed-in object.

public class ComplexBuilder implements Builder {
   private ArrayList builders = new ArrayList();
   public void add(Builder b) {
      public Object build(Object o) {
         Object tempObj = null;
      for (int i = 0; i < this.builders.size(); i++) {
         Builder builder = (Builder) builders.get(i);
         o = builder.build(o);
      return o;

Please see the source code for the executable example.

Here is a UML representation of this pattern.

Even though the concept is simple, the places to apply this pattern could be difficult to find when designing an enterprise application. To see where to use this pattern, architects need to look for instances in the design where data or objects are created or modified. Builder can be applied where something is morphed from smaller parts into a final product. Most text formatting for onscreen presentation that involves several steps, such as concatenations, lower or upper case conversion, numeric formatting, and so forth, can benefit from this pattern. See the included source for an example.

Page 1 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that developer.com may send you developer offers via email, phone and text message, as well as email offers about other products and services that developer believes may be of interest to you. developer will process your information in accordance with the Quinstreet Privacy Policy.


We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date