Wednesday, 14 January 2009

Design Patterns Java™ Workbook - Part12

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 (23-24).

1) A strategy is a plan, or approach, for achieving an aim, given certain input conditions.A strategy is similar to an algorithm: An algorithm is a well-defined procedure that produces an output from a set of inputs. A strategy is a plan that pursues an output given a set of inputs.Usually, however, a strategy has more latitude in how to pursue its goal than an algorithm does. This latitude also means that strategies often appear in groups, or families, of alternatives. When multiple strategies are available, the logic that surrounds the strategies must select one and then execute it. Complexity in the selection and use of strategies can lead to complex and tangled code. You can clean up such code with the STRATEGY pattern.

2) The intent of STRATEGY is to encapsulate alternative strategies, or approaches, in separate classes, each of which implements a common operation. The strategic operation defines the inputs and output of a strategy but leaves implementation up to the individual classes. Classes that implement the various approaches implement the same operation and are thus interchangeable, presenting the same interface to clients.

3) The refactored code consists almost entirely of simple methods in simple classes. This is an advantage in its own right and makes adding new strategies easy. The refactoring relies primarily on the idea of distributing an operation across a related group of classes. In this regard, STRATEGY is identical to STATE. In fact, many developers wonder whether these are really different patterns.

4) Strategies that occur in the real world may not naturally lie down as separate methods in a collection of classes. Logic that models alternative strategies may appear in a single class,often in a single method. Such methods may be too complicated and may mix strategyselection logic with strategy execution.

To simplify such code, create a group of classes, one for each strategy. Define an operation and distribute it across these classes. This lets each class encapsulate one strategy, creating simpler code. You also need to arrange for the client that uses a strategy to be able to select one. This selection code may be complex even after refactoring, but you should be able to reduce this code so that it is nearly equivalent to pseudocode that describes strategy selection in the problem domain.

5) Polymorphism lets you encapsulate a request, or a command as an object: Establish the signature of a method to call, and vary the effect of calling the method by varying the implementation. The COMMAND pattern establishes a method signature, most often execute() or perform(), and lets you define various implementations of this interface.This lets you encapsulate a request as an object, so that you can parameterize clients with different requests, queue, time, or log requests, and require companion operations, such as undo().

6) The COMMAND pattern has interesting relationships to many other patterns. For example,COMMAND provides an alternative to TEMPLATE METHOD.

7) The COMMAND pattern affords an alternative design to a TEMPLATE METHOD for hooks and is similar in intent, or structure, to several other patterns. The COMMAND pattern is similar to ADAPTER.

8) The COMMAND pattern lets you encapsulate a request in an object so that you can modify at runtime the method that a client will call. A classic example of the usefulness of COMMAND comes with menus. Menus know when to execute an action but don't know which method to call. COMMAND lets you parameterize a menu with the method calls that correspond to menu labels.

9) COMMAND fixes the signature of an operation and lets classes vary, applying this trick of polymorphism to encapsulate an operation in an object. Perhaps because this idea is so fundamental, COMMAND has interesting relationships to many other patterns. COMMAND can be an alternative to MEDIATOR or TEMPLATE METHOD and often interacts with other patterns.

No comments: