Scribd
Upload
25 views29 pages

90 DesignPatterns

The document discusses several design patterns including Singleton, Observer, Decorator, Factory, Adapter, State, and MVC. It provides examples of when and how to use each pattern, highlighting benefits like loose coupling, flexibility, and code reuse. Design patterns are necessary for large projects but should be used judiciously as they are not always applicable solutions.

Uploaded by

DEEP725
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
25 views29 pages

90 DesignPatterns

The document discusses several design patterns including Singleton, Observer, Decorator, Factory, Adapter, State, and MVC. It provides examples of when and how to use each pattern, highlighting benefits like loose coupling, flexibility, and code reuse. Design patterns are necessary for large projects but should be used judiciously as they are not always applicable solutions.

Uploaded by

DEEP725
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 29

Design Patterns

OO-Concepts
• Don’t rewrite code
• Encapsulation
• Inheritance
• Write flexible code
Design Patterns
• Time to level up!
• Necessary when the projects are large
• Course projects (possibly including CSE442)
– Small projects
– Requirements don’t change
– No design patterns needed
– Can get away without proper OO usage
• Large projects with poor design
– Do you want to refactor 10,000 lines of code?
– 100,000 lines?
Caution
• Design patterns should be used in moderation
• This is a hammer
– Not all problems are nails
Let’s learn these
• Singleton
• Observer pattern
• Decorator Pattern
• Factory Pattern
• //Command pattern
• Adapter Pattern
• State pattern
• MVC
Singleton
• There can be only one!
• When your codebase needs to share a single
object (not a single class)
• Private constructor
– What?
• Controversial
– Introduces global state
Singleton
Singleton
• No need to pass the settings in every
constructor and function call
• Can cause issues
– What if I want multiple sets of settings
concurrently?
– Panic
– Then run multiple instances of the program and
let the OS take care of it
Lazy Initialization
• Don’t create an object until it’s about to be
used
• If an object is never used, it’s never created
• Can prevent multiple instantiations
• Can greatly improve efficiency
• At least spreads out the computation
– If that’s what you’re into
Observer Pattern
• A single object has many other objects that
need to know when it updates
• On an update, broadcast to all concerned
objects
• But how?
• Thermostat temp sensor
– Furnace
– AC
– Mobile app
Observer Pattern
Observer Pattern
• Loose coupling
• Observers can be registered and unregistered
during runtime
– Flexible
– Dynamic
• No need to hardcode and notify every
possible object that might ever be concerned
• Subject is only coded once
– This is a big deal!
Scenario
• Inspired from Head First Design Patterns
• Need to compute the cost of a burger
• Condiments cost extra
Burger $1.50
Ketchup $0.05
Relish $0.10
Cheese $0.50
Scenario
• How do we adjust to added requirement?

Burger $1.50
Ketchup $0.05
Relish $0.10
Cheese $0.25
Bacon $0.50
Scenario
• Customer orders double cheese and triple
bacon
Decorator Pattern
• Wrapper classes
• Add features by adding wrapper classes
• Outer object interacts with the world
• Original/inner object is hidden
• Especially useful when original class is in a
library and lacks needed funtionality
Decorator Pattern
Decorator Pattern
Food Item
cost()

Condiment
Burger
-Food Item
cost()
cost()

Ketchup Relish Cheese Bacon


cost() cost() cost() cost()
Scenario
• Need to create an enemy (abstract class)
• Type of enemy (concrete class) depends on:
– Player’s level
– Player’s location
– Some randomness
• Enemies are created throughout the codebase
• What do you do?
Factory Pattern
• A class that makes objects
– Don’t all classes do that?
• Factory pattern
– Create objects of an abstract type
– No concern about the concrete class that’s
instantiated
Adapter Pattern
• Interface between 2 different protocols
• Don’t modify the source code of either
• Often needed when combining code bases
– Libraries
• Your code uses a single interface
• Adapters extend the interface and make
external function calls
Library we need expects this:

Our code is built around this:


Adapter Pattern
State Pattern
• CSE116
– Make a program without using “if”
• CSE396
– DFA’s
• Delegate functionality to a state object
• Functionality changes as state chnges
State Pattern
State Pattern
MVC
• Model
– Where all the action
• View
– What the user sees
– Outputs
• Controller
– How the user interacts
– Inputs

You might also like