CSC/ECE 517 Fall 2012/ch1b 2w41 dc

State pattern and the related patterns

The State pattern allows an object to completely change its behavior and the change depends on its current internal state. Alternatively, a monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state. State pattern is closely related to Strategy pattern and Bridge pattern. We shall discuss the three patterns, their structures, advantages & disadvantages.

Description

In this section, each of the three patterns is discussed along with their structure and examples.

State Pattern

The state pattern is behavioral as it defines how communication between classes or entities is controlled. It is used in programming to define the state of an object. This pattern, also called as object for states pattern <ref>http://en.wikipedia.org/wiki/State_pattern</ref>, allows the class of an object to change at runtime without changing the interface used to access the object or losing the current state. This change in class is abstracted with the use of a wrapper object or context.<ref>http://www.blackwasp.co.uk/State.aspx</ref>

Creating object oriented state machines is one of the uses of the state pattern. In this, the functionality of the object changes fundamentally according to its state. Using multiple concrete classes, each class inheriting from the same base class is an alternative to multiple number of 'if' or 'switch' statements.

Structure

Following is the general structure of state pattern<ref>http://www.cs.umd.edu/class/fall2002/cmsc433-0101/Lectures/designPatterns2.pdf</ref>:

• Context: Used by the clients of the state pattern which do not access the state objects directly. It holds a ConcreteState object according to the current state.

• State: Abstract base class of all ConcreteState classes. No state is defined in this class or its subclasses.

• Concrete States: The concrete state classes implement the real functionality that will be used by the Context object. ConcreteState A, ConcreteState B etc. in the figure are the states of the Context and implement the Handle().

Example

One of the most common examples for State pattern is implementation of an alarm clock. This implementation has four states: Off, On, Snooze and Buzz. The following figure depicts the state diagram of an alarm clock:

Strategy Pattern

Strategy pattern allows a set of similar algorithms to be defined and encapsulated in their own classes (BW). This pattern is used to create multiple interchangeable family of algorithms and a specific algorithm can be selected at run time according to the configuration details or user preferences. It increases flexibility as new algorithms can be added easily.

Structure

Following is the general structure of Strategy pattern:<ref>http://www.blackwasp.co.uk/Strategy.aspx</ref>

• Client: This is the user of interchangeable algorithm which has a property to hold one of the strategy classes selected at runtime.

• StrategyBase: This is an abstract base class for all the classes which can include multiple methods. This can also be implemented as an interface.

• ConcreteStrategy A/B: Each of the ConcreteStrategy classes implement one algorithm which can be used by the client.

Example

One of the most common examples of Strategy pattern is File Encryption. For encrypting a small file, in-memory strategy can be used, which reads the whole file into memory. Whereas for a large file, parts of file are read into the memory and encrypted partial results are stored in temporary files.

Bridge Pattern

Bridge pattern separates abstract elements of a class from its implementation. This can be used to achieve cleaner implementation of real world objects and it allows easy changes in implementation. For instance, business logic of an element can be the abstract elements of a class which can be created independent of the implementation details of their data access. This makes the business logic independent of databases etc.

Unlike State pattern, Bridge pattern is structural as it defines how relationships can be created between classes or entities.

Structure

Following is the general structure of Bridge pattern:<ref>http://www.blackwasp.co.uk/Bridge.aspx</ref>

• Abstraction: This is a base class for other abstractions and it contains members that define abstract business objects. An object of this type holds a reference to a particular implementation for different platform specific applications.

• RefinedAbstraction: Each RefinedAbstraction provides more specific implementation of Abstraction.

• ImplementationBase: This is an abstract class and acts as a base class for all classes providing implementation. This could be defined as an interface if no functionality is being provided for its subclasses.

• ConcreteImplementation: This is responsible for providing platform specific functionality.

Example

The most common example of a bridge pattern is Device Drivers. Device vendors would need interface specifications and they are defined using bridge pattern.

Chain of Responsibility

Chain of Responsibility pattern helps decouple the sender of a request and receiver of a request in a chain of multiple handler objects. When a system receives a request, only one handler object from its chain of handlers can process the request. If the object however cannot serve the request then it will determine the next handler object in the chain of responsibility and push the request forward in the chain. In the chain of handler objects, the responsibility of determining who to serve the request is left to the objects participating in the chain.<ref>http://tinyurl.com/brkg9py</ref>

Structure

Following is the general structure of Chain of Responsibility:<ref>http://www.dofactory.com/Patterns/PatternChain.aspx</ref>

• Handler: This is a base class for ConcreteHandler objects that defines an interface for handling the requests. It may or may not implement the successor link.

• ConcreteHandler: These are the request handler objects that constitute the chain of responsibility. It handles the requests sent to it by a Client or another ConcreteHandler object. If the ConcreteHandler can handle the request it does so; otherwise is will forward the request to its successor. It can access its successor.

• Client: This initiates the request to a ConcreteHandler object in the chain of Handler that may handle the command.

Example

Exception Handling in Java uses chain of responsibility in deciding how to handle an exception. A sequence of exceptions is listed in catch statements and when there is an exception thrown, this list is scanned one by one from top. If a catch statement can handle the exception then the job is done, otherwise it is passed to the next catch block and so on until it reaches the finally block.

References

<references/>