State Pattern

17
1 State Pattern • Intent » Alter behaviour of an object when its internal state changes » Object appears to change its class Alternate names Objects for states

description

State Pattern. Intent Alter behaviour of an object when its internal state changes Object appears to change its class Alternate names Objects for states. State – Motivation. An object may be in one of many states. It responds differently depending upon its current state Example - PowerPoint PPT Presentation

Transcript of State Pattern

Page 1: State Pattern

1

State Pattern

• Intent

» Alter behaviour of an object when its internal state changes

» Object appears to change its class

• Alternate names

Objects for states

Page 2: State Pattern

2

State – Motivation

• An object may be in one of many states. It responds differently depending upon its current state

» Example

> A Room can be in one of the states– Alright, SomeFaults, ManyFaults

> A request to paint the room is made– Alright state – clean and paint room

– SomeFaults– repair yourself and paint room

– ManyFaults– hire contractor and paint room

Page 3: State Pattern

3

State – Example Structure

*ROOM_STATE

paint *furnish *

+ROOM

paintfurnish

+MANY_FAULTS

paint +

furnish +

+ALRIGHT

paint +

furnish +

+SOME_FAULTS

paint +

furnish +

state

Page 4: State Pattern

4

State – Abstract Structure

+CONTEXT

operation

*STATE

operation *

operation +

+A_STATE

state.operation

state

Page 5: State Pattern

5

State – Participants

• Context

Defines client interface

• Deferred State

Defines interface for common behaviour for different states

• Effective State

Implements behaviour of that state in context

Page 6: State Pattern

6

State – Collaborations

• Context delegates state specific behaviour to a concrete state object

• Context may pass itself as an argument so that state can access context features

• Context is the primary interface with clients

» Clients configure context with state objects

» Clients do not deal directly with state objects

• Context or concrete state can decide which state follows another state

Page 7: State Pattern

7

State – Applicability

• Object has different behaviour depending on state

• Operations have multi-part conditional statement dependent upon state

» State is represented by an enumerated constant

» Several operations have same conditional structure

• Pattern puts each branch of the conditional into a separate class

» Object’s state becomes an object that can vary independently of other objects

Page 8: State Pattern

8

State – Related Patterns

• State objects are often Singletons

» Frequently, state classes do not contain any attributes

» As a result, state objects of the same type are all the same

» To avoid having many different objects that are exactly the same, one can make such classes singletons

Page 9: State Pattern

9

Composite Pattern

• Intent

» Compose objects into tree structures representing part-whole hierarchies

» Clients deal uniformly with individual objects and hierarchies of objects

Page 10: State Pattern

10

Composite – Motivation

• Applications that have recursive groupings of primitives and groups

» Drawing programs

lines, text, figures and groups

» Eiffel static structure

classes and clusters

• Operations on groups are different than primitives but users treat them in the same way

Page 11: State Pattern

11

Composite –  Drawing Example

DIAGRAM

DIAGRAMTEXT LINE

DIAGRAM

OVAL TEXT

DIAGRAM

OVAL TEXT

Page 12: State Pattern

12

Composite – Example Architecture

LINE +

draw +

DIAGRAM +

draw +

add +

remove +

iterate +

GRAPHIC *draw *

TEXT +

draw +

OVAL +

draw +

COMPOSITE[T] *add *

remove *

iterate *

CLIENTT

Page 13: State Pattern

13

Composite – Abstract Architecture

COMPOSITE_COMPONENT +

op_1 +

op_2 +

add +

remove +

iterate +

COMPONENT *op_1 *op_2 *

COMPOSITE[T] *add *

remove *

iterate *

CLIENTT

LEAF +

op_1 +

op_2 +

Page 14: State Pattern

14

Composite – Applicability

• Represent part-whole hierarchies of objects

• Clients can ignore difference between individual objects and compositions

• Clients deal with all objects in a composition in the same way

Page 15: State Pattern

15

Composite – Participants

• Component

Defines properties of an entity

• Leaf

Defines properties of a primitive entity

• Composite

Declares properties of a collection of entities

• Composite Component

Combines properties of a collection of entities and properties of a primitive entity

• Client

Uses component and composite properties

Page 16: State Pattern

16

Composite – Consequences

• Whenever client expects a primitive it can accept a composite

• Client is simplified by removing tag-case statements to identify parts of the composition

• Easy to add new components by subclassing, client does not change

• If compositions are to have restricted sets of components have to rely on run-time checking

Page 17: State Pattern

17

Composite – Related Patterns

• Decorator is a degenerate Composite (only one component)

• Visitor localizes operations that would be distributed across composite and leaf classes