February 20, 2019
Hot Topics:

Build and Command Objects-Using Design Patterns

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

Other uses can be more complex changes to an object's properties. Imagine you have a Value Object that is populated with database values and is passed back to the client level (JSP or any other technology) via an HTTP response. Based on some values, an appropriate action will be taken before the client sees the server response. For example, if some data is not correct, the client may see an error page and not the page with the values. Value Object is a holder of data and its concepts can be considered another design pattern, but this topic is not in the scope of this article.

Builder can be used to check data in the Value Object and modify it, before it reaches the client tier. It can set flags, add or format fields in the Value Object, and then pass it onward.

Another application of this pattern could be even more complex, where actual new objects are created based in the interface. For instance, the above "build" method returns a generic "Object," but it could return a specific interface and any class that implements it. Therefore, based on the business rules, which a concrete builder implements, it can take one object and return a completely different one.

The build possibilities are endless for "Builder" pattern.

Command Pattern

Command is a behavioral pattern; that puts it in the category of Observer design pattern. Observer pattern is beyond the scope of this article, but anyone who used modern listeners should be familiar with its concept. Command deals with behavior and does not create new types of objects like the Builder does. For example, this pattern is often used in GUIs where a menu item object can be connected with different Commands in such a way that the menu item object does not need to know any details of how action is performed.

Its intent is to "encapsulate a request as an object, thereby letting [developers] parameterize clients with different requests, and supports undoable operations."

Here is an UML diagram of this pattern:

Look at some code to make this pattern clear:

The Receiver object is the one that performs action on the behalf of the command and it can be any action dictated by the business logic even a Builder action, via a public interface.

class Receiver
   public void action()
      System.out.println("Performing action or build operation");

Instead of an interface, an abstract class can be used to define the command.

public abstract class Command
   protected Receiver receiver;
   public Command( Receiver receiver )
      this.receiver = receiver;
   public abstract void execute();

The concrete Command class, therefore, need not to have Receiver field defined.

public class ConcreteCommand extends Command {
   ConcreteCommand(Receiver receiver) {
   public void execute() {

Please see the included source for a complete implementation.

In an enterprise application, "receivers" can be supplied on the fly to the "command" objects, and "commands" can be attached to visual components that don't need to know how the action is done. For example, in the Swing GUI, a different instance of the same concrete command object can be attached to different buttons or drop-down menu Items and perform different actions based on the command Receiver's implementations.

As I mentioned, Receiver can be combined with the Builder pattern. In other words, an action method could also be a build method. This way, when there is a request for a command to be done, the same request also can perform a build action.

By placing "Builder" object as a Receiver of the "Command," truly powerful results can be achieved. Programmers can build and command objects, at the same time enforcing code reuse, strict interface following and logic flow, in your design.


In this article, I have covered the basis of creational "Builder" and behavioral "Command" patterns, and have shown how to use them in an overall architecture design. I also have shown how to look for places to apply them. I firmly believe that architects need not only know these patterns, but also have a strong understanding on where these patterns fit on the overall design; that sometimes can be harder than just knowing them.

Download the Code

You can download the source code used in this article here.



Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
Publisher: Addison-Wesley Professional; 1st edition (January 15, 1995)
ISBN: 0201633612

Head First Design Patterns
by Elisabeth Freeman, Eric Freeman, Bert Bates, and Kathy Sierra
Publisher: O'Reilly; 1st edition (October 26, 2004)
ISBN: 0596007124



Wikipedia online: http://en.wikipedia.org/wiki/

About the Author

Vlad Kofman is a Senior System Architect working on projects under government defense contracts. He has also been involved with enterprise-level projects for major Wall Street firms and the U.S. government. His main interests are object-oriented programming methodologies and design patterns.

Page 2 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.

Thanks for your registration, follow us on our social networks to keep up-to-date