Feature

While creational patterns decouple a client from the objects it instantiates, behavioral patterns dictate the object interaction. If not carefully planned, coupling and cohesion can pose major design issues. My previous article, "Java GoF Creational Design Patterns" (JDJ, Vol. 9, issue 9), discussed creational patterns. This article will focus on behavioral patterns.

Knowledge of the behavioral pattern vocabulary will help designers come up with appropriate solutions for object interactions, minimizing or eliminating these issues. One basic thing to understand is that there are two kinds of patterns:

• Class: Describes compile-time relationship between classes via inheritance
• Object: Describes the runtime relationship between classes via composition

The patterns elicited in this article have been classified as either object or class based. Generally, object patterns allow more flexibility in design.

When working with design patterns, it's important to know not just how but also when to use them. A design pattern should occur naturally as a part of a design and shouldn't drive the design, but guide it. Overuse of any pattern is harmful, especially in a situation where you're biased, desperately trying to fit a pattern into the design. If you look at the Golden Hammer anti-pattern (an anti-pattern is the reverse of a design pattern), it states just that: when you are already well versed with a particular pattern, and overuse a technology or pattern, then learn or implement a more befitting technology/pattern to the domain/problem in question. It is prudent to look at the domain and problem context first and then use patterns to help in the design process.

At a bare minimum, you should strive for a loosely coupled design and program to an interface rather than an implementation. This leads to a good design without forcing you to apply design patterns in a problem context. Patterns are meant to aid designers, not compel the designers to use them.

It's also not a good idea to override an implemented method of a base class or derive from a concrete class. If you also adhere to not having a variable holding a reference to a concrete class, together this qualifies the dependency (or inversion) principal that can also be used as a guideline for design.

In accordance with my earlier article on creational patterns, I'll attempt to keep this one terse as well, simultaneously keeping ease of understanding as the denominator.

Table 1 lists the behavioral patterns with their intent. Our next step will be to validate each one with a laconic, yet usable template. Each pattern will have a standard definition, template, and description attached to it. I will then attach a real-world example in which the respective pattern shall be applicable. Together, these elements will help you understand the patterns from the perspective of a software manager, architect, designer, or developer.

Strategy Pattern
This pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. It allows algorithms to vary independently of the clients that use it.

The Strategy pattern is widely used and suggests programming to an interface over implementation. It allows building dynamic software that can be changed with minimal impact on existing code.

Let's look at the template below:

1. The first step is to define an interface Strategy. This defines a method that each ConcreteStrategy shall implement (there can be more than one ConcreteStrategy).
2. The Context class encapsulates the Strategy interface.
3. Now this is ready to be used. A client can create a Context object and dynamically assign the ConcreteStrategy at runtime.

Strategy is an object pattern. If this solution were to be approached via inheritance (as in a class pattern), it would not allow the flexibility to dynamically bind ConcreteStrategy to Context.

Template

package strategy;

public interface Strategy {

	/**
	 * This method declaration must be implemented by the ConcreteStrategy
	 implementations.
	 */
	public void algorithmInterface();
}

package strategy;

public class Context {

	/** stores the Strategy instance of the Context */
	private final Strategy fStrategy;

	/** * Constructor */
	public Context(Strategy strategy) {super()
		fStrategy = strategy;
	}

	/**
	 * This method invokes the algorithm interface of the current Strategy
	 */
	public void contextInterface() {fStrategy.algorithmInterface();
	}
}

package strategy;

public class ConcreteStrategy implements Strategy {

	public ConcreteStrategy() {super();
	}

	/**
	 * This method implements the algorithm operation defined by the Strategy
	 interface.
	 */
	public void algorithmInterface() {
	// Write your algorithm code here ...
	}

}

Example
Imagine a scenario in which a company is interviewing for different positions. The recruiter wants to schedule the interviews with the flexibility to change the position that a candidate might interview for. To apply the above template:

	Strategy = Position
	Context = Candidate
	ConcreteStrategy1 = DotNET
	ConcreteStrategy2 = J2EE
	ConcreteStrategy3 = CPlusPlus