The Bridge Design Pattern

The State Design Pattern Aamir Siddiqui University of Scranton SE 516 – Dr Bi

Contents

1. Classification 2. Intent 3. In 30 Seconds 4. Motivation 5. Use 6. Structure 7. CODE example 8. Conclusions 9. Extra Help

Classification There is one of three classifications that all design patterns fall into:

1. Creational 2. Structural and 3. Behavioral.

The State Pattern is classified as a behavioral design pattern.

PURPOSE Creational Structural Behavioral Scope Class Factory Method Adapter (class) Interpreter Template Method Object Abstract Factory Adapter (object) Chain of Responsibility Builder Bridge Command Prototype Composite Iterator Singleton Decorator Mediator Façade Mermento Flyweight Observer Proxy State Strategy Visitor

Intent Allow an object to alter its behavior when its internal State changes. The object will appear to change its class.

The main intention here is to manage sequence of events of same type.

If you understand finite state machine then you already know this pattern.

In 30 Seconds The catch here is ‘Implementing discrete object states using explicit classes’. Many a times we deal with objects, which have a number of discrete states and the object’s behavior depends on the flow of State transitions. It is a run time pattern meaning that it can change its state at anytime, if the user wants to.

Motivation The main objective of this design pattern is to efficiently handle scenarios where message collection is involved. This involves counting the received messages and recognizing the point where collection has been completed. Structure

Structure of State

“Context” class: Represents the interface to the outside world.

“State” abstract class: Base class, which defines the different states of the “state machine”.

“Derived” classes from the State class: Defines the true nature of the state that the state machine can be in. Context class maintains a pointer to the current state. To change the state of the state machine, the pointer needs to be changed.

Motivation The main objective of this design pattern is to efficiently handle scenarios where message collection is involved. This involves counting the received messages and recognizing the point where collection has been completed.

 Digit collection  Collecting periodic sanity punch from a hardware unit.  Collecting message segments to form a complete message. This technique is used in several segmentation and reassembly protocols.

CODE example

An object's getColor() method is different if the "color" property of the given object is set to "blue" instead of "red" because getColor() returns a different value in the two situations.

Furthermore, the object may make decisions at run time as to exactly what to do dependent upon the values its properties possess. For instance, if the sky is blue (sky.setColor(Color.blue)), then the sun should be visible. public boolean sunIsVisible() { if(getColor()==Color.blue) { return true; } else { return false; } }

One issue with the above solution is that it is a hard-coded logic solution, not an architect solution. The sky does not intrinsically behave a certain way if it is blue, but rather it should figure out what to do in that situation. Wouldn't it be better if the sky intrinsically acted properly if it were blue? One could imagine two objects: a SkyBlue and a SkyNonBlue.

The SkyBlue class' sunIsVisible() method would always return true while the SkyNonBlue version would always return false.

What one needs now is the ability for a sky object to dynamically (i.e. at run time) change its class to/from SkyBlue and SkyNonBlue. What we'd like to accomplish is called "dynamic reclassification".

We've seen code that does change its specific behavior depending on what particular strategy was installed. So, the setColor() method could install a strategy that would always return true if its sunIsVisible() method were to be called.

Conclusions

The State pattern is a solution to the problem of how to make behavior depend on state.

 Define a "context" class to present a single interface to the outside world.  Define a State abstract base class.  Represent the different "states" of the state machine as derived classes of the State base class.  Define state-specific behavior in the appropriate State derived classes.  Maintain a pointer to the current "state" in the "context" class.  To change the state of the state machine, change the current "state" pointer.

Extra Help

http://ootips.org/state-pattern.html