CSC/ECE 517 Fall 2012/ch1b 2w41 dc: Difference between revisions
Line 28: | Line 28: | ||
=== Example === | === 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. | 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: | ||
[[File:Alarm_state.PNG|400px]] | [[File:Alarm_state.PNG|400px]] | ||
Revision as of 21:33, 19 November 2012
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:
- 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.
References
<references/>