Design Patterns Java™ Workbook - Part11

Couple of Days back i started reading Design Patterns Java™ Workbook By Steven John Metsker.

Nice book written by Steven John Metsker.

I wanted to share few quotations found the book from the next 2 chapters (21-22).

1) In a sense, almost every method is a template. Ordinary methods have bodies that define a sequence of instructions. It is also quite ordinary for a method to invoke methods on the current object and on other objects. Ordinary methods are, in this sense, "templates" that merely outline a series of instructions for the computer to follow. The TEMPLATE METHOD pattern, however, involves a more specific type of template.

2) When you write a method, you may want to define the outline of an algorithm, understanding that there may be differences in how you want to implement certain steps. In this case, you can define the method but leave some steps as abstract methods, as stubbed-out methods, or as methods defined in a separate interface. This produces a more rigid "template" that specifically defines which steps of an algorithm other classes can or must supply. The intent of TEMPLATE METHOD is to implement an algorithm in a method, deferring the definition of some steps of the algorithm so that other classes can redefine them.

3) A Classic Example of Template Method: Sorting

An ancient example of TEMPLATE METHOD that is not only pre-Java but also prehistoric occurs in sorting.1 Sorting has various algorithms, but in most settings, you can establish a single algorithm and use it to sort various collections of objects. Any algorithm that you use for sorting will rely on the primitive step of comparing two items, or attributes. If you can compare, say, the sharpness of two arrowheads, your sorting algorithm will let you sort the arrowheads in a collection.

4) Template Method Hooks

A hook is a method call that a developer places in his or her code to give other developers a chance to insert code at a specific spot in a procedure. When you are adapting another developer's code and you need control at a point where you don't currently have it, you can request a hook. An obliging developer can add a method call at the point that you need it.The developer will also usually supply a stubbed-out version of the hook method so that other clients need not necessarily override the hook method.

Ordinary methods are usually templates in that you can't tell exactly what code will execute just by looking at a single method. The TEMPLATE METHOD pattern, however, does not merely note that ordinary methods are templates. Rather, the intent of TEMPLATE METHOD is to define an algorithm in a method, leaving some steps abstract, stubbed out, or defined in an interface so that other classes can fill them in.

TEMPLATE METHOD often functions as a contract between developers. One developer supplies the outline of an algorithm, and another developer supplies a certain step of the algorithm. This may be a step that lets the algorithm complete, or it may be a step that the algorithm developer includes to hook in your code at specific points in the procedure.

The intent of TEMPLATE METHOD does not imply that you will always write the template method in advance of defining subclasses. You may discover similar methods in an existing hierarchy. In this case, you may be able to distill the outline of an algorithm and move it up to a superclass, applying TEMPLATE METHOD to simplify and to organize your code.

5) The state of an object is a combination of the current values of its attributes. When you call a set- method, you typically change an object's state, and an object can change its own state as its methods execute.

In some cases, an object's state can be a prominent aspect of its behavior, such as when modeling transactions and machines. Logic that depends on the object's state may spread through many of the class's methods. To counter this spread, you can move state-specific behavior into a group of classes, with each class representing a different state. This lets you avoid having deep or complex if statements, relying instead on polymorphism to execute the right implementation of an operation. The intent of the STATE pattern is to distribute state-specific logic across classes that represent an object's state.

6) Generally speaking, the state of an object depends on the collective value of the object's instance variables. In some cases, an object's state can be a prominent aspect of a class's behavior. This often occurs when an object is modeling a real-world entity whose state is important. In such a situation, complex logic that depends on the object's state may appear in many methods. You can simplify such code by moving state-specific behavior to a hierarchy of state objects. This lets each state class contain the behavior for one state in the domain. It
also allows the state classes to correspond directly to states in a state machine.

7) To handle transitions between states, you can let states retain a context reference that contains a set of states. Alternatively, you can pass around, in state transition calls, the object whose state is changing. Regardless of how you manage state transitions, the STATE pattern simplifies your code by distributing an operation across a collection of classes that represent an object's various states.