The document explains the state design pattern, a behavioral design pattern that enables an object to alter its behavior based on its internal state changes, closely related to finite state machines. It outlines the structure, pros and cons, and provides examples of its applicability in various contexts, such as document management and TCP/IP protocols. Additionally, it contrasts the state pattern approach with traditional state management methods that rely on complex conditional statements.

1. STATE PATTERN
Software Design and Architecture
Presented by
• Khadija Noor BSEF20A512
• Tania BSEF20A508

2. Agenda
■ What is State Pattern?
■ Relation to Finite State Machines
■ Structure
■ Pros and Cons
■ Applicability and Use cases
■ Pseudocode
■ Notable Usage

3. What is the State Design Pattern?
■ The State Design Pattern is a behavioral design pattern that allows an object
to change its behavior when its internal state changes. This pattern is
particularly useful when an object’s behavior depends on its state, and the
state can change during the object’s lifecycle.
■ The object will appear to change its class.
■ It is also known as Object for States.

4. Relation to the Finite State Machine
■ The State pattern is closely related to the concept of a Finite-State
Machine.
■ The main idea is that, at any given moment, there’s a finite number
of states in which a program can be in. Within any unique state, the
differently, and the program can be switched from one state to another
instantaneously. However, depending on the current state, the program may
or may not switch to certain other states. These switching rules,
called transitions, are also finite and predetermined.

5. Motivation
■ Imagine that we have a
Document class. A document can
be in one of three states: Draft,
Moderation, and Published. The
publish method of the document
works a little bit differently in
each state:
■ In Draft, it moves the document
to moderation.
■ In Moderation, it makes the
document public, but only if the
current user is an administrator.
■ In Published, it doesn’t do
anything at all.

6. State Machine based Solution
■ State machines are usually
implemented with lots of
conditional statements (if or
switch) that select the appropriate
behavior depending on the current
state of the object
■ Issue in this Approach:
Most methods will contain
monstrous conditionals that
pick the proper behavior of a
method according to the
current state. Code like this is
very difficult to maintain
because any change to the
transition logic may require
changing state conditionals in
every method. The problem
tends to get bigger as a project
evolves.

7. State Pattern Based Solution
■ The State pattern suggests that
you create new classes for all
possible states of an object and
extract all state-specific
behaviors into these classes.
■ Instead of implementing all
behaviors on its own, the original
object, called context, stores a
reference to one of the state
objects that represents its
current state and delegates all
the state-related work to that
object.

8. Structure of the State Pattern

9. Pros and Cons

10. Applicability and its
Use Cases

11. Applicability

12. Traffic Light Transitions

13. Gaming Transitions

14. Pseudocode

16. Context Class

18. State Interface

19. Concrete States

20. Ready State

21. Playing State

22. Use of State Design Pattern in TCP/IP
■ Ralph Johnson and Jonathan Zweig characterize the State pattern and its
application to TCP connection protocols

23. References
■ Design Patterns: Elements of Reusable Object-Oriented Software
■ Ralph E. Johnson and Jonathan Zweig. Delegation in C++. Journal of Object-Oriented
Programming, 4(11):22–35, November 1991.
■ https://refactoring.guru/design-patterns/state
■ https://www.geeksforgeeks.org/state-design-pattern/
■ https://www.ashishvishwakarma.com/GoF-Design-Patterns-by-Example/State-
Pattern/
■ https://medium.com/well-red/state-machines-for-everyone-part-1-introduction-
b7ac9aaf482e
■ https://networkinterview.com/11-states-of-tcp-transition-explained/