DEV Community: Prateek Prabhakar

The Only Design Pattern Cheat Sheet You'll Need Before Interviews

Prateek Prabhakar — Mon, 01 Sep 2025 05:14:13 +0000

You've probably read a lot about design patterns, most of them have long explanations, heavy UML diagrams, and abstract examples that are hard to connect with real life.
But let's be honest, when you're preparing for a tech interview, you don't need a textbook. You need a quick, crisp, memorable guide that tells you,

What the pattern is
Why it exists
A real world hook to remember it
A tiny pseudo code snippet for recall

That is exactly what this Design Pattern Cheat Sheet is.
Think of it as your one stop destination to revise all design patterns in minutes, with hooks and analogies that will stick in your head when interview pressure hits.
And if you want to go deeper, don't worry, I have already written detailed articles for each pattern. You'll find the links next to each one for a full deep dive.

Creational Patterns

Creational design patterns are like a set of blueprints or recipes for creating objects. They separate the process of HOW objects are created from the code that actually USES them. This makes our code more flexible and easier to change later on.

1.Factory Method

// Interface
Interface Sender
    Method Send(msg)

// Concrete products
Class EmailSender implements Sender
    Send(msg) → print "Email: " + msg

Class SmsSender implements Sender
    Send(msg) → print "SMS: " + msg

// Creator
Abstract Class NotificationCreator
    Abstract Method CreateSender()

Class EmailCreator extends NotificationCreator
    CreateSender() → new EmailSender()

Class SmsCreator extends NotificationCreator
    CreateSender() → new SmsSender()

// Caller
creator = new EmailCreator()
sender  = creator.CreateSender()
sender.Send("Hey! How are you doing?")

2.Abstract Factory

// Abstract Factory
Interface UIFactory
    Method CreateButton()
    Method CreateInput()

// Concrete factories
Class DarkFactory implements UIFactory
    CreateButton() → new DarkButton()
    CreateInput()  → new DarkInput()

Class LightFactory implements UIFactory
    CreateButton() → new LightButton()
    CreateInput()  → new LightInput()

// Caller
factory = new DarkFactory()
btn = factory.CreateButton()
inp = factory.CreateInput()

3.Prototype

// Prototype interface
Interface Document
    Method Clone()

// Concrete prototype
Class Invoice implements Document
    Property header, footer
    Clone() → return shallowCopy(this)

// Caller
invoice1 = new Invoice("Logo A", "Thanks")
invoice2 = invoice1.Clone()
invoice2.footer = "Updated Footer"

4.Singleton

// Singleton
Class Config
    Private static instance
    Private Constructor()

    Static Method GetInstance()
        If instance == null
            instance = new Config()
        return instance

// Caller
c1 = Config.GetInstance()
c2 = Config.GetInstance()
// c1 == c2

5.Builder

Class Notification
    Props: Title, Message, IsEmail, IsSMS, IsPush, Priority

Class NotificationBuilder
    Constructor() -> this.n = new Notification()
    Method SetTitle(t)         -> n.Title = t; return this
    Method SetMessage(m)       -> n.Message = m; return this
    Method EnableEmail()       -> n.IsEmail = true; return this
    Method EnableSMS()         -> n.IsSMS   = true; return this
    Method EnablePush()        -> n.IsPush  = true; return this
    Method WithPriority(p)     -> n.Priority = p; return this
    Method Build()             -> return n

// Caller
notification = new NotificationBuilder()
                 .SetTitle("Big Sale!")
                 .SetMessage("50% off today")
                 .EnableEmail()
                 .EnablePush()
                 .WithPriority("High")
                 .Build()

Structural Patterns

Structural design patterns are a set of rules for putting together classes and objects to create bigger, more useful systems. They are all about composition, which means combining objects instead of relying solely on inheritance. Think of it like building with LEGOs, you are fitting different pieces together to make a larger, more complex model.

6.Adapter

// Old interface
Class LegacyPayment
    Method MakePayment(amount)

// Adapter
Class PaymentAdapter implements NewPayment
    legacy = new LegacyPayment()
    Pay(amount) → legacy.MakePayment(amount)

// Caller
p = new PaymentAdapter()
p.Pay(100)

7.Decorator

// Base
Interface Coffee
    Method Cost()

Class SimpleCoffee implements Coffee
    Cost() → 50

// Decorator
Class MilkDecorator implements Coffee
    coffee
    Constructor(c) → coffee = c
    Cost() → coffee.Cost() + 20

// Caller
coffee = new MilkDecorator(new SimpleCoffee())
print coffee.Cost()   // 70

8.Composite

// Component
Interface FileSystemItem
    Display(indent)

// Leaf
Class File implements FileSystemItem
    Display(i) → print i + "File"

// Composite
Class Folder implements FileSystemItem
    items = []
    Add(item) → items.Add(item)
    Display(i)
        print i + "Folder"
        For item in items → item.Display(i+1)

// Caller
root = new Folder()
root.Add(new File())
root.Display(0)

9.Facade

// Subsystems
Class Lights
    Method Dim()

Class TV
    Method TurnOn()

// Facade
Class HomeTheaterFacade
    Method StartMovieNight()
        Lights.Dim()
        TV.TurnOn()

// Caller
theater = new HomeTheaterFacade()
theater.StartMovieNight()

10.Proxy

// Subject
Interface Service
    Request()

// Real subject
Class RealService implements Service
    Request() → print "Real work done"

// Proxy
Class ServiceProxy implements Service
    real = new RealService()
    Request()
        print "Proxy check..."
        real.Request()

// Caller
s = new ServiceProxy()
s.Request()

11.Flyweight

// Flyweight
Class Character
    symbol
    Constructor(s) → symbol = s

// Factory
Class CharFactory
    cache = {}
    GetChar(s)
        If not in cache → cache[s] = new Character(s)
        return cache[s]

// Caller
c1 = factory.GetChar("A")
c2 = factory.GetChar("A")
// same instance

12.Bridge

// Implementor
Interface Device
    TurnOn()

Class TV implements Device
    TurnOn() → print "TV On"

// Abstraction
Class Remote
    device
    Constructor(d) → device = d
    Press() → device.TurnOn()

// Caller
r = new Remote(new TV())
r.Press()

Behavioral Patterns

Behavioral design patterns are about defining how objects interact and communicate with each other. They focus on delegating responsibilities and ensuring objects can work together effectively without being tightly coupled. Think of them as the traffic rules for our code. They manage the flow of requests and the assignment of tasks between different objects.

13.Strategy

// Strategy
Interface Coupon
    Apply(amount)

// Concrete strategies
Class Flat50 implements Coupon
    Apply(amount) → amount - 50

Class TenPercent implements Coupon
    Apply(amount) → amount * 0.9

// Caller
coupon = new Flat50()
print coupon.Apply(500)

14.Observer

// Subject
Class Channel
    subs = []
    AddSub(s) → subs.Add(s)
    Upload(video)
        For s in subs → s.Notify(video)

// Observer
Class User
    Notify(v) → print "New video: " + v

// Caller
ch = new Channel()
usr = new User()
ch.AddSub(usr)
ch.Upload("Design Patterns")

15.Command

// Command
Interface Command
    Execute()

Class LightOn implements Command
    Execute() → print "Light ON"

// Invoker
Class Remote
    Set(cmd) → this.cmd = cmd
    Press() → cmd.Execute()

// Caller
remote = new Remote()
remote.Set(new LightOn())
remote.Press()

16.Chain of Responsibility

// Handler
Abstract Class Handler
    next
    SetNext(h) → next = h
    Handle(req)
        If next != null → next.Handle(req)

// Concrete
Class Manager extends Handler
    Handle(req)
        If req < 1000 → print "Manager handled"
        Else super.Handle(req)

// Caller
mgr = new Manager()
dir = new Director()
mgr.SetNext(dir)
mgr.Handle(2000)

17.State

// State
Interface State
    Play()

Class HappyState implements State
    Play() → print "Party music"

Class SadState implements State
    Play() → print "Sad songs"

// Context
Class MusicPlayer
    state
    SetState(s) → state = s
    Play() → state.Play()

// Caller
mp = new MusicPlayer()
mp.SetState(new HappyState())
mp.Play()

18.Mediator

// Mediator
Class ChatRoom
    Send(msg, user) → print user + ": " + msg

// Colleague
Class User
    name, room
    Send(msg) → room.Send(msg, name)

// Caller
room = new ChatRoom()
u1 = new User("Alice", room)
u1.Send("Hello!")

19.Momento

// Memento
Class Snapshot
    state
    Constructor(s) → state = s

// Originator
Class Editor
    text
    Save() → new Snapshot(text)
    Restore(snap) → text = snap.state

// Caller
e = new Editor()
e.text = "v1"
snap = e.Save()
e.text = "v2"
e.Restore(snap)  // back to v1

20.Template Method

// Abstract
Class Game
    Play()
        Init()
        Start()
        End()

// Concrete
Class Football extends Game
    Init() → print "Setup field"
    Start() → print "Kickoff"
    End()   → print "Game over"

// Caller
g = new Football()
g.Play()

21.Visitor

// Visitor
Interface Visitor
    Visit(Book)

// Element
Class Book
    Accept(v) → v.Visit(this)

// Concrete visitor
Class TaxVisitor implements Visitor
    Visit(b) → print "Taxing book"

// Caller
book = new Book()
visitor = new TaxVisitor()
book.Accept(visitor)

22.Iterator

// Iterator
Interface Iterator
    HasNext()
    Next()

Class ProductIterator implements Iterator
    list, index=0
    HasNext() → index < list.Length
    Next() → list[index++]

// Caller
it = new ProductIterator(products)
while it.HasNext()
    print it.Next()

23.Interpreter

Interface Expression
    Method Interpret(product): bool

Class CategoryExpression implements Expression
    Constructor(category)
    Method Interpret(product) -> product.Category == category

Class PriceExpression implements Expression
    Constructor(limit)
    Method Interpret(product) -> product.Price < limit

Class AndExpression implements Expression
    Constructor(left, right)
    Method Interpret(product) -> left.Interpret(product) 
                                      AND right.Interpret(product)

// Usage
rule = new AndExpression(
          new CategoryExpression("Electronics"),
          new PriceExpression(1000))

For each product in products
    If rule.Interpret(product)
        Print "Selected: " + product.Name

Design patterns aren't about throwing jargon in interviews. They are about writing clean, extensible, and maintainable code.
This cheat sheet is meant to be your last minute revision buddy, something you can glance at before an interview and instantly recall the essence of each pattern.
Remember,

There is no need to memorize patterns, instead it is important to understand the problem each one solves.
Use the hooks and analogies here to explain patterns in a simple, story like way during interviews.
When coding, reach for patterns not because they are "fancy," but because they make your design clearer and future proof.

With this in your toolkit, I am sure you will walk into interviews not just knowing the names of the patterns, but with the confidence to explain and apply them in real world scenarios.

Happy coding, and may your designs always stay simple and scalable!

Design Patterns Simplified: Part 22 — Interpreter Pattern (a.k.a. “The Rule Engine”)

Prateek Prabhakar — Wed, 27 Aug 2025 10:43:25 +0000

The Interpreter Pattern belongs to the Behavioral category of design patterns.
Why? Because it is all about defining a simple grammar and then interpreting statements written in that grammar.

Bigger question is why do we even need it?
The Interpreter Pattern is used when your system needs to read, understand, and act on sentences written in a mini language (domain-specific language). Instead of hardcoding all possible variations, you define a grammar (rules) and let the system evaluate them dynamically.

Think about traffic signs. A red circle with a line means No Entry, a green light means Go. You do not memorize every road individually, instead, just interpret symbols using predefined rules.

It applies effectively to below scenarios too.

Search filters → "category = 'Electronics' AND price < 1000"
Validation rules → "Age > 18 AND Country = 'India'"
Math expressions → "5 + 10 - 2"

Each of these is a sentence in some domain specific language.
The Interpreter Pattern lets you define the grammar (rules + symbols) and then evaluate/interpret sentences accordingly.

The Language Teacher

Suppose you are learning Spanish. Instead of memorizing every possible sentence, your teacher gives you rules,

“hola” → “hello”
“gracias” → “thank you”
Grammar: Sentence = Word1 + Word2 + ...

Now, when you see “hola amigo”, you don’t need a separate hardcoded translation. You apply rules recursively to interpret the whole sentence.

That is the Interpreter Pattern in action - Rules + Recursive interpretation.

Search Filters in E-commerce

Let's say you are building a product search system for an e-commerce application. Users can define filters like,

Category = "Electronics"
AND
Price < 1000

You want your system to interpret this rule and filter products accordingly.

What Does the Code Look Like?

// Step 1: Common Expression interface
Interface Expression
    Method Interpret(product) : bool

// Step 2: Terminal Expressions (basic rules)
Class CategoryExpression implements Expression
    Property category

    Constructor(category)
        this.category = category

    Method Interpret(product)
        return product.Category == category

Class PriceExpression implements Expression
    Property priceLimit

    Constructor(priceLimit)
        this.priceLimit = priceLimit

    Method Interpret(product)
        return product.Price < priceLimit

// Step 3: Non-Terminal Expressions (combinators)
Class AndExpression implements Expression
    Property left : Expression
    Property right : Expression

    Constructor(left, right)
        this.left = left
        this.right = right

    Method Interpret(product)
        return left.Interpret(product) AND right.Interpret(product)

Class OrExpression implements Expression
    Property left : Expression
    Property right : Expression

    Constructor(left, right)
        this.left = left
        this.right = right

    Method Interpret(product)
        return left.Interpret(product) OR right.Interpret(product)

// caller logic
products = [
    {Name:"iPhone", Category:"Electronics", Price:900},
    {Name:"Shoes", Category:"Fashion", Price:120},
    {Name:"Laptop", Category:"Electronics", Price:1500}
]

// Rule: Category = "Electronics" AND Price < 1000
rule = new AndExpression(
            new CategoryExpression("Electronics"),
            new PriceExpression(1000))

// Evaluate rule against all products
For each product in products
    If rule.Interpret(product)
        Print "Selected: " + product.Name

// output:
Selected: iPhone

Here, we defined a common Expression interface.
CategoryExpression and PriceExpression are terminal expressions → basic rules.

AndExpression and OrExpression are non-terminal expressions → combine rules.

The client builds a rule tree (Electronics AND Price < 1000), and the system evaluates each product using Interpret().

What Did We Achieve?

Abstraction of rules : Client does not hardcode logic for category/price.
Extensibility : You can add new filters (BrandExpression, RatingExpression) easily.
Reusability : Complex rules can be built from smaller ones.
Flexibility : Rules are simply objects, which can be stored, combined, reused.

When Should You Use the Interpreter Pattern?

When you have to process and evaluate expressions (math, rules, filters).
When the grammar is simple and stable.
When you want to allow dynamic rules instead of hardcoding logic.

Use Cases?

E-commerce search filters
Rule-based engines (validation, business policies)
Query interpreters (SQL-like structures in domain specific language)
Formula calculation engines

Note:

Interpreter pattern is not about machine translation like English → French. It is about defining a grammar and providing a way to interpret statements written in that grammar.

If the grammar is very complex, Interpreter can lead to large class hierarchies. In such cases, parser generators or compilers are a better fit.

People confuse it with these patterns, Strategy Pattern (choosing one algorithm at runtime) - but Interpreter is about grammar + evaluating sentences, not choosing algorithms. Facade Pattern (simplifying subsystems) - Interpreter is not about simplification, it is about parsing + evaluating rules.

To summarize, it would be apt to say,

The Interpreter Pattern is like having a language teacher for your code. Instead of hardcoding every possible sentence, you define rules (grammar), and the system interprets them recursively.

It shines when you want flexible, extensible, rule-based evaluation.

Hope now you have a good understanding of the Interpreter pattern and its applications.

This marks the end of our series - Design Patterns Simplified.

Next up: Design Patterns Simplified - Cheat Sheet. The only design pattern sheet you need to look at before your next tech interview.

Design Patterns Simplified: Part 21 — Facade Pattern (a.k.a. “The One-Stop Counter”)

Prateek Prabhakar — Mon, 25 Aug 2025 04:44:12 +0000

The Facade Pattern belongs to the Structural category of design patterns.
Why? Because it hides complex subsystems behind a simple interface, making the client’s life easier.

Say you are travelling to your favorite holiday destination. You enter the airport an walk to the check-in counter. You would not directly deal with baggage handling, seat assignment, boarding pass generation etc. Instead, you walk up to one counter, hand over your passport, and the staff takes care of all the background steps by coordinating with multiple systems.

That is the Facade Pattern in action. You can think of it as a single, simplified entry point to a complex set of operations.

The Smart Home

Imagine you have a smart home with many subsystems like Lights, Air Conditioner, Security Camera, Music System.

Say its Friday and you decide to have a movie night. You would want to have the stage set for it to have a wonderful experience.

Without Facade you would have to, talk to each subsystem directly - lights, AC, TV, speakers. The client code becomes a to-do list of commands and is tightly coupled to the subsystem details. Any small change (say, new speakers) forces changes everywhere.

With Facade, you just call one method - "StartMovieNight", and its all set.

What Does the Code Look Like?

// Step 1: Subsystems
Class Lights
    Method TurnOn()
    Method Dim()

Class AirConditioner
    Method TurnOn()
    Method SetTemperature(temp)

Class TV
    Method TurnOn()
    Method SetInput(input)

Class Speakers
    Method TurnOn()
    Method SetMode(mode)

// Step 2: Facade
Class HomeTheaterFacade
    Property lights
    Property ac
    Property tv
    Property speakers

    Constructor(lights, ac, tv, speakers)
        this.lights = lights
        this.ac = ac
        this.tv = tv
        this.speakers = speakers

    Method StartMovieNight()
        lights.Dim()
        ac.TurnOn()
        ac.SetTemperature(22)
        tv.TurnOn()
        tv.SetInput("HDMI")
        speakers.TurnOn()
        speakers.SetMode("Theater")

// caller logic
lights = new Lights()
ac = new AirConditioner()
tv = new TV()
speakers = new Speakers()

homeTheater = new HomeTheaterFacade(lights, ac, tv, speakers)
homeTheater.StartMovieNight()

We define individual subsystem classes (Lights, AC, TV, Speakers), with each having its own detailed operations.
Instead of the client calling these classes directly, we introduce HomeTheaterFacade.

The facade exposes a single method StartMovieNight(), which internally coordinates all the subsystem calls in the right sequence.

This makes the client’s job super easy. Its just one call that does it all for you.

What Did We Achieve?

Simplicity: Clients deal with one simple interface instead of multiple complex subsystems.
Loose Coupling: Clients aren not tied to subsystem details. If internals change, the facade shields them.
Reusability: Common workflows that have complex subsystems synchronized can be packaged into facade methods.

When Should You Use the Facade Pattern?

When your system has multiple subsystems that are complex or frequently change.
When you want to provide a simplified entry point for common tasks.
When you want to reduce dependencies between client code and low level operations.

Use Cases?

Holiday booking websites : one interface coordinates flights, hotels, cars, activities
Payment gateways : single call hides multiple banking/payment subsystems
Libraries/Frameworks : where a facade API wraps complex underlying logic

To summarize, it would be apt to say,

The Facade Pattern is like your airport check-in counter, one simple stop that takes care of a whole set of complex behind the scenes processes. Hiding the complexities and getting the work done with just a single entry point.

Hope this gave a good idea on the Facade Pattern.

Next up: Interpreter Pattern. Stay tuned!

BONUS: Relation to Adapter & Mediator

Facade is often confused with two patterns - Adapter & Mediator. Here is a quick comparison between the three.

Adapter : It focuses on compatibility. Makes two incompatible interfaces work together. Example, plugging a US charger into an EU socket.

Facade : It focuses on simplicity. Hides a complex subsystem behind a clean, unified interface.

Mediator : It focuses on communication. Defines how objects interact with each other without them referring to each other directly.

Design Patterns Simplified: Part 20 — Iterator Pattern (a.k.a. “The Product Browser”)

Prateek Prabhakar — Fri, 22 Aug 2025 11:50:19 +0000

The Iterator Pattern belongs to the Behavioral category of design patterns.
Why? Because it is all about how you access elements in a collection without exposing its internal structure.

Imagine you are at a buffet. Cravings!!!
You don’t really care how dishes are stored in the kitchen or in which order the chef cooked them. You simply move along the buffet line and take one dish after another.

That’s what the Iterator Pattern does for collections in code. It lets you move through items sequentially without knowing how they are actually stored (array, tree, linked list, etc.).

The E-commerce Product Catalog

Suppose you are building a product catalog for an online store. The catalog might store products in different ways, maybe an array, maybe a list fetched from a database, or even a cache.

The challenge? You want to give customers a consistent browsing experience without caring about the underlying storage.
In comes the iterator pattern to help you out.

What Is the Iterator Pattern?

This pattern provides a way to sequentially access elements of a collection without exposing how the collection is implemented.
So, instead of writing different loops for arrays, lists, or DB queries, you just ask the iterator,

HasNext() → Is there another product?
Next() → Show me the next product.

What Does the Code Look Like?

// Step 1: Define a Product class
Class Product
    Property name
    Property price

    Constructor(name, price)
        this.name = name
        this.price = price

// Step 2: Define the Iterator interface
Interface Iterator
    Method HasNext() : Boolean
    Method Next() : Product

// Step 3: Concrete Iterator for a List of Products
Class ProductIterator implements Iterator
    Property products
    Property position = 0

    Constructor(products)
        this.products = products

    Method HasNext()
        Return position < products.Count

    Method Next()
        product = products[position]
        position = position + 1
        Return product

// Step 4: Define Collection Interface
Interface ProductCollection
    Method CreateIterator() : Iterator

// Step 5: Concrete Product Catalog
Class OnlineStoreCatalog implements ProductCollection
    Property products = []

    Method AddProduct(product)
        products.Add(product)

    Method CreateIterator()
        Return new ProductIterator(products)

// caller logic
catalog = new OnlineStoreCatalog()
catalog.AddProduct(new Product("Laptop", 800))
catalog.AddProduct(new Product("Headphones", 100))
catalog.AddProduct(new Product("Keyboard", 50))

iterator = catalog.CreateIterator()

While iterator.HasNext()
    product = iterator.Next()
    Print "Browsing product: " + product.name 
       + " ($" + product.price + ")"

Let me explain on what's happening in the code above. We have the below components that work in tandem to help achieve the iterator pattern.

Product → It is a simple class holding product details like name and price.

Iterator interface → A contract that says, “Any iterator must at least know how to check if there is another item (HasNext()) and how to return the next one (Next()).”

ProductIterator → The actual implementation of an iterator for a product list. It keeps track of your current position and knows how to move forward.

ProductCollection interface → Another contract that says, “Any product collection should be able to give an iterator.”

OnlineStoreCatalog → It is the concrete product collection. It stores products internally, but instead of exposing them directly, it gives you an iterator when asked (CreateIterator()).

The end user only interacts with the iterator and not the collection itself. They just keep asking,

“Do you have another product?” → “Okay, give it to me.”

The key here is that the client does not need to know how products are stored (list, array, DB fetch). They only interact with the iterator, which provides a consistent way to browse.

What Did We Achieve?

Abstraction: The client does not need to know how products are stored, they can simply iterate over them.
Consistency: A uniform way to browse products, regardless of underlying data structure.
Flexibility: You can change the collection’s implementation (array, DB, API) without touching client code.

When Should You Use Iterator Pattern?

When you want a uniform way to traverse different types of collections.
When you do not want to expose the internal structure of a collection.
When collections might change, but client code should remain stable.

Use Cases?

As you might have already guessed, the Iterator Pattern shows up all around us.

E-commerce product catalogs : browse through thousands of products page by page without knowing the storage backend.
Social media feeds : scroll through posts, reels, or stories in sequence.
Photo gallery apps : swipe through images one by one, regardless of how they’re stored on disk.
Music or video playlists : play next, previous, or shuffle without exposing the internal list.
File browsing : move through folders and files seamlessly.

To summarize, it would be apt to say,

The Iterator Pattern is like giving your customers a “Next Product” button in your store. They don’t care how the products are stored, instead, they just keep browsing smoothly.

It is one of those patterns that keeps your application user friendly and your code future proof.

Hope this article helped you understand the Iterator Pattern and where to apply effectively.

Next up: Facade Pattern. Stay tuned!

Bonus: Iterator + Composite Pattern - A Perfect Duo

Remember the Composite Pattern we covered earlier (like file/folder structures or org charts)? It helps you organize objects into a hierarchy, where individual items and groups are treated the same.

Now, here’s where Iterator steps in as the perfect partner: it gives you a clean way to walk through that hierarchy.

Take a file–folder system as an example,

Composite lets you represent folders that can contain files or even other folders.
Iterator then allows you to seamlessly move through these items, whether you are looping through files in one folder or traversing the entire tree.

In short, Composite organizes, Iterator navigates.
Together, they make working with hierarchical data both neat and effortless.

Design Patterns Simplified: Part 19 — Composite Pattern (a.k.a. “The File Tree Organizer”)

Prateek Prabhakar — Wed, 20 Aug 2025 16:57:20 +0000

The Composite Pattern belongs to the Structural category of design patterns.
Why? Because it allows you to treat individual objects and groups of objects uniformly, by organizing them into a tree like hierarchy.

Think about a Company Org Chart.

An Employee can be a individual contributor.
A Manager is also an employee, but they can have multiple employees reporting to them.

Now, when their details are needed in order to distribute festive coupons, you don’t want different logic for developers and managers. You would just want to call the same method, and the right thing should happen.

This is exactly what the Composite Pattern does in code. It lets you work with single objects (referred as leaves) and collections of objects (referred as composites) through a common interface.

The File System

Suppose you are building a file explorer application. You want it to be able to display both Files and Folders.
But a Folder can contain Files as well as other Folders, and you don’t want to write separate logic for each.

So, the challenge here is - How do you treat individual items and groups of items in the same way?

Enter the Composite Pattern. It lets you represent part-whole hierarchies (like trees) where individual objects and groups are treated uniformly.

What does the code look like?

// Step 1: Define a common interface
Interface FileSystemItem
    Method Display(indentLevel)

// Step 2: Leaf class (File)
Class File implements FileSystemItem
    Property name

    Constructor(name)
        this.name = name

    Method Display(indentLevel)
        Print indentLevel * "-" + " File: " + name

// Step 3: Composite class (Folder)
Class Folder implements FileSystemItem
    Property name
    Property items = List of FileSystemItem

    Constructor(name)
        this.name = name

    Method Add(item)
        items.Add(item)

    Method Display(indentLevel)
        Print indentLevel * "-" + " Folder: " + name
        For each item in items
            item.Display(indentLevel + 1)

// caller logic
root = new Folder("Root")
root.Add(new File("Resume.docx"))
root.Add(new File("Budget.xlsx"))

projects = new Folder("Projects")
projects.Add(new File("AppDesign.pdf"))
projects.Add(new File("Prototype.png"))

root.Add(projects)

root.Display(0)

//output
Folder: Root
- File: Resume.docx
- File: Budget.xlsx
- Folder: Projects
-- File: AppDesign.pdf
-- File: Prototype.png

In the above code, we define a common interface FileSystemItem and both File and Folder implement the same interface. This ensures we can call Display() on either of them without worrying about whether it is a file or a folder.

We have a Leaf (File) which represents a single object (like Resume.docx). The Display() method just prints its own name with indentation.

There is another class Composite (Folder) that holds a collection of FileSystemItem(both files and folders). Its Display() method first prints the folder name, then recursively calls Display() on each child item.

This recursive call builds the tree-like structure.

In short, the Composite Pattern hides the complexity of “is this a single item or a group?”. You just treat everything as a FileSystemItem. The recursion inside Folder handles the hierarchy behind the scenes.

What Did We Achieve?

Unified treatment: Files and Folders can be handled with the same operations.
Scalability: You can add new types (like shortcuts, archives) easily without breaking existing code.
Tree structures: Perfect for hierarchical data like file systems, menus, or org charts.

When Should You Use the Composite Pattern?

When your objects naturally form a tree structure (like files, menus, or employees).
When you want to treat individual and composite objects uniformly.
When you want to simplify client code by avoiding if-else checks for single vs group.
When new leaf or composite types should be easy to add without changing client logic.

Use Cases?

File Systems (Files and Folders)
UI Components (Buttons, Panels, Windows)
Organization Structures (Employee vs Manager hierarchy)
Menu Systems (Single menu item vs Submenu)

To summarize, it would be apt to say,

The Composite Pattern is like your File Tree. You don’t care whether you are dealing with a single File or a whole Folder. Both are items, and you can work with them in the same way.

This keeps your code simple, extensible, and a lot cleaner whenever hierarchical structures come into play.

Composite works hand in hand with the Iterator Pattern. We will be diving into it next!

Design Patterns Simplified: Part 18 — Bridge Pattern (a.k.a. “The Music Connector”)

Prateek Prabhakar — Mon, 18 Aug 2025 14:15:35 +0000

The Bridge Pattern belongs to the Structural category of design patterns.
Why? Because it helps us split two related objects so they can grow independently, without stepping on each other’s toes.

Think of it like using a Universal Remote. With this you can control different brands of TVs, sound systems, or streaming boxes, without buying a separate remote for each.
That is because the remote and the device work independently but together through a common connection.

The Music Connector

Say you have just bought a brand new smart speaker. Party time indeed !!
It looks sleek, sounds amazing, and you can’t wait to blast your favorite playlist.

But here’s the catch,
You are a Spotify person, your partner loves Apple Music, and your friend is always on YouTube Music.

Now imagine if the manufacturer had to build a different speaker for every streaming service, like,

Smart Speaker + Spotify
Smart Speaker + Apple Music
Smart Speaker + YouTube Music

… and the same for phones, car stereos, and every other music device.

That would be absolute madness. We would end up having a storage room full of almost identical devices, each tied to just one service.

Thankfully, that is not how it works in real life.
Instead, your device (phone, speaker, car stereo) and your music service (Spotify, Apple Music, YouTube Music) are independent, yet they work together seamlessly. You can mix and match however you like.

That is the Bridge Pattern in action.
It is the “connector” that lets two separate worlds (in our example - devices and services) interact without being locked into each other.

What is the Bridge Pattern?

The Bridge Pattern helps you separate an abstraction from its implementation so that both can evolve independently.
In our music example,
Abstraction → The device (Phone, Smart Speaker, Car Stereo)
Implementation → The streaming service (Spotify, Apple Music, YouTube Music)

Instead of creating every possible combination as a separate class, we “bridge” the two so they can connect dynamically.

What does the code look like?

// Step 1: Define the "Implementor" interface (MusicSource)
Interface MusicSource
    Method PlayMusic()

// Step 2: Concrete Implementations of MusicSource
Class Spotify implements MusicSource
    Method PlayMusic()
        Print "Playing music from Spotify..."

Class YouTubeMusic implements MusicSource
    Method PlayMusic()
        Print "Playing music from YouTube Music..."

Class AppleMusic implements MusicSource
    Method PlayMusic()
        Print "Playing music from Apple Music..."


// Step 3: Define the "Abstraction" (Device)
Class MusicDevice
    Property musicSource  // reference to a MusicSource

    Constructor(musicSource)
        this.musicSource = musicSource

    Method Play()
        musicSource.PlayMusic()


// Step 4: Refined Abstractions (Specific Devices)
Class Phone extends MusicDevice
    Constructor(musicSource)
        super(musicSource)

Class CarStereo extends MusicDevice
    Constructor(musicSource)
        super(musicSource)

Class SmartSpeaker extends MusicDevice
    Constructor(musicSource)
        super(musicSource)


//caller logic
spotify = new Spotify()
youtube = new YouTubeMusic()

phone = new Phone(spotify)
phone.Play()      // Output: Playing music from Spotify...

carStereo = new CarStereo(youtube)
carStereo.Play()  // Output: Playing music from YouTube Music...

Here is how the above code works,

You (the caller) decide which Device (e.g., SmartSpeaker, CarStereo) you want and which Music Source (e.g., SpotifyService, YouTubeMusicService) it should play from.
When creating the device, you pass the chosen music source into the device’s constructor. This is the “bridge” that connects the two worlds.
Device (Abstraction): The device defines high level actions like PlayMusic() or StopMusic(). It does not know how the music service works, instead, it just calls the music service’s methods.
Music Service (Implementor): Each music service (Spotify, YouTube Music, etc.) implements its own logic for playing/streaming music.
The device simply delegates to this service without caring about its details.

In short,
You call myDevice.Play() → The device calls musicSource.PlayMusic() internally → The music service does its work and returns control back to the device.

What Did We Achieve?

With this approach, the devices and music services are separate. You can add a new device without touching any music service code, or add a new music service without touching any device code. The constructor injection is the handshake that makes them work together without being tightly coupled.

When Should You Use the Bridge Pattern?

When you have two dimensions of change, for example, different devices and different music sources, and you want them to evolve independently.
When subclass explosion is a risk. Without Bridge, you would need a class for every combination (e.g. CarStereoWithSpotify, CarStereoWithYouTubeMusic, etc.).
When you want loose coupling between high level logic (device) and low level details (music service), so changes on one side don’t break the other.
When future scalability matters. You can add new variations of either side without touching the other side’s code.

Use Cases?

Payment systems (different payment methods + different platforms)
UI Themes (different themes + different components)
Messaging apps (different message senders + different protocols)

To summarize, it would be apt to say,

The Bridge Pattern is like using a universal remote that works with different brands of TVs, separating the remote (abstraction) from the TV (implementation) so both can evolve independently without messing each other up.

Hope this made the Bridge Pattern easy to grasp!

Next up: Composite Pattern. See you there!

Design Patterns Simplified: Part 17 — Flyweight Pattern (a.k.a. “The Shared Furniture”)

Prateek Prabhakar — Fri, 15 Aug 2025 10:16:42 +0000

The Flyweight Pattern belongs to the Structural category.
Why? Because it helps you save memory by sharing common parts of objects instead of creating duplicates.

Think about a hotel with many rooms. All these rooms need chairs, tables, and lamps. Instead of buying unique furniture for every room, which is costly and takes up variable space in each room, the hotel buys a limited number of identical furniture pieces and reuses them across many rooms.
This sharing saves money and space, while each room still keeps its own layout and style (like where the furniture is placed or extra decorations).

The Text Editor

Suppose you are building a Text Editor app that handles large documents.
Each character in the document is an object with properties like font, size, and color.

If you create a separate object for every character including its style properties, your app will quickly consume a lot of memory.

So, the challenge here is, How do you reduce memory usage when you have many similar objects (characters with same style) repeated throughout the document?

Enter the Flyweight Pattern

The Flyweight Pattern lets you share common parts of objects (called intrinsic state) and store only unique parts (called extrinsic state) separately.
This reduces memory usage by reusing shared data instead of duplicating it.

What does the code look like?

// Step 1: Define the Character interface
Interface Character
    Method Display(positionX, positionY)

// Step 2: Concrete Character Class (Flyweight)
Class ConcreteCharacter implements Character
    Property symbol        // intrinsic state, shared
    Property font
    Property size
    Property color

    Constructor(symbol, font, size, color)
        Set properties

    Method Display(positionX, positionY)
        Print "Displaying '" + symbol + "' at ("
             + positionX + "," + positionY + ") with font="
             + font + ", size=" + size + ", color=" + color

// Step 3: Flyweight Factory to manage shared objects
Class CharacterFactory
    Property characters = Dictionary of (symbol+font+size+color)
                             -> ConcreteCharacter

    Method GetCharacter(symbol, font, size, color)
        key = symbol + font + size + color
        If characters contains key Then
            Return characters[key]
        Else
            character = new ConcreteCharacter(symbol, font, size, color)
            characters[key] = character
            Return character

//caller logic (text editor)
factory = new CharacterFactory()

// For each character in document
charA1 = factory.GetCharacter('A', 'Arial', 12, 'Black')
// Reuses same object as charA1
charA2 = factory.GetCharacter('A', 'Arial', 12, 'Black')  

charB = factory.GetCharacter('B', 'Arial', 12, 'Black')

charA1.Display(10, 20)
charA2.Display(15, 20)
charB.Display(20, 20)

The CharacterFactory ensures that characters with the same intrinsic properties (symbol, font, size, color) are shared i.e. only one object is created and reused.
The unique part, like position, is passed as extrinsic state during method calls.

What Did We Achieve?

Saved memory by sharing common parts of objects.
Avoided creating many duplicate objects with the same properties.
Kept unique parts separate by passing them externally when needed.

When Should You Use the Flyweight Pattern?

When you have many similar objects that differ only in a few properties.
When you want to optimize memory usage in your app.
When object creation is costly or you want to reduce resource consumption.

Use Cases?

Text editors handling lots of characters.
Graphical apps rendering many shapes with shared properties.
Game development where many objects share textures or models.
Caching and object pooling.

Does the Flyweight Pattern look similar to the Prototype pattern?

Yes. It is often confused with the Prototype pattern, but let's understand the difference,

Flyweight Pattern (Structural): It focuses on sharing common parts of objects (called intrinsic state) to save memory when many similar objects exist. Instead of creating many full objects every time needed, it reuses shared data and passes unique information separately. This is great for optimizing resource use when you have lots of similar objects with small differences.

Prototype Pattern (Creational): It is about creating new objects by cloning an existing object (a prototype). It allows you to quickly generate copies with the same state as the original, which can then be modified independently. This is useful when object creation is costly or complex, and you want to create new objects efficiently by copying.

To summarize, it would be apt to say,

The Flyweight Pattern is like furnishing hotel rooms by sharing furniture i.e. saving memory and resources while still allowing each room to have unique arrangements.

Hope this made the Flyweight Pattern easy to understand!

Next up: Bridge Pattern. Please come over!

Design Patterns Simplified: Part 16 — Proxy Pattern (a.k.a. “The Gatekeeper”)

Prateek Prabhakar — Wed, 13 Aug 2025 14:26:58 +0000

The Proxy Pattern belongs to the Structural category.
Why? Because it controls access to an object by providing a placeholder or “proxy” that manages how and when the real object is accessed.

Think of it like, you want to enter a VIP party, but first, you meet the gatekeeper.
The gatekeeper checks your invitation and only lets you in if everything is good. You don’t talk to the party organizer directly. It is the gatekeeper who controls your access.

The Image Viewer

Suppose you are building an Image Viewer app that loads high resolution images. Loading these images is slow and uses a lot of memory.

You don’t want to load every image at once when the gallery opens. Instead, you want to load an image only when the user actually wants to see it.

So, the challenge here is - How do you delay loading the heavy image without changing how the rest of the app accesses it?

Enter the Proxy Pattern

The Proxy Pattern provides a placeholder object (proxy) that looks like the real object and controls access to it. The proxy implements the same interface as the real object, so the app can use it seamlessly.
But the proxy handles the loading or access logic, for example, loading the image only when requested.

What does the code look like?

//Step 1: Define the Image interface
Interface Image
    Method Display()

//Step 2: Real Image Class
Class RealImage implements Image
    Property filename

    Constructor(filename)
        this.filename = filename
        LoadFromDisk()

    Method LoadFromDisk()
        Print "Loading " + filename + " from disk..."

    Method Display()
        Print "Displaying " + filename

//Step 3: Proxy Image Class
Class ProxyImage implements Image
    Property realImage
    Property filename

    Constructor(filename)
        this.filename = filename
        this.realImage = null

    Method Display()
        If realImage == null Then
            // Load image only when needed
            realImage = new RealImage(filename)  
        End If
        realImage.Display()

// Caller Logic
images = [new ProxyImage("photo1.jpg"), new ProxyImage("photo2.jpg")]
// Images are NOT loaded yet

images[0].Display()  // Loads and displays photo1.jpg
images[1].Display()  // Loads and displays photo2.jpg
images[0].Display()  // Displays photo1.jpg without loading again

ProxyImage looks just like RealImage because both implement the same Image interface.
But the proxy controls when the real image is loaded. It loads the image only when Display() is called for the first time.
This saves memory and improves performance without changing how the rest of the app uses the images.

What Did We Achieve?

Controlled access to a heavy object.
Delayed expensive object creation until needed (lazy loading). Lazy loading is implemented by delaying the creation (and loading) of the RealImage object until the Display() method is actually called.
Kept client code unchanged by using the same interface for proxy and real object.

When Should You Use the Proxy Pattern?

When you want to control access to an object (security, logging).
When creating the real object is expensive, and you want to delay it until necessary.
When you want to add extra functionality (like caching or access control) without changing the real object.

Use Cases?

Virtual Proxy: Lazy loading large images, files, or data.
Remote Proxy: Representing an object in a different address space (e.g. across a network).
Protection Proxy: Controlling access based on permissions.
Logging Proxy: Logging access to the real object’s methods.

Is the Proxy Pattern Confused with Any Other Pattern?

Yes. It is often confused with the Decorator Pattern.
Both deal with object structure, but here is the difference,
Proxy: Controls access and can delay or restrict it.
Decorator: Adds new behaviors dynamically without controlling access.

To summarize, it would be apt to say,

The Proxy Pattern is like having a gatekeeper who controls when and how you get access to something valuable, making your system efficient and secure.

Hope this helped you understand the Proxy Pattern clearly!

Next up: Flyweight Pattern. Let’s learn about it…

Design Patterns Simplified: Part 15 — Visitor Pattern (a.k.a. “The VIP Guest”)

Prateek Prabhakar — Mon, 11 Aug 2025 13:05:45 +0000

The Visitor Pattern falls under the Behavioral category.
Why? Because it is all about defining new operations on objects without changing their classes.

Say you have a VIP guest who can visit different rooms in a building. The guest behaves differently in each room, but instead of rewriting each room’s code, you just allow the guest to visit and decide what to do there.

Let's understand this with another example, diving deep this time.

The Document Processor

Imagine you are building an application that works with different types of documents - Word, PDF, and Spreadsheet.
You want to run operations like Spell check, Export to HTML, or Count words.

The Problem

If you add each new operation directly into the document classes, you will keep changing those classes every time. Overtime your classes would become messy, repetitive, and more importantly it breaks the Open/Closed Principle (classes should be open for extension, but closed for modification).

Enter the Visitor Pattern

The Visitor Pattern lets you add new operations without changing your document classes.

Each document has an Accept(visitor) method. Its a way of saying

“Come in and do your work"

Each visitor knows exactly how to handle each document type.

What does the code look like?

//Step 1: Define the Visitor Interface
Interface DocumentVisitor
    Method VisitWordDocument(wordDoc)
    Method VisitPdfDocument(pdfDoc)
    Method VisitSpreadsheet(sheet)

//Step 2: Define the Document Interface
Interface Document
    Method Accept(visitor)

//Step 3: Concrete Document Classes
Class WordDocument implements Document
    Method Accept(visitor)
        visitor.VisitWordDocument(this)

Class PdfDocument implements Document
    Method Accept(visitor)
        visitor.VisitPdfDocument(this)

Class Spreadsheet implements Document
    Method Accept(visitor)
        visitor.VisitSpreadsheet(this)

//Step 4: Create Concrete Visitors (Operations)
Class SpellCheckVisitor implements DocumentVisitor
    Method VisitWordDocument(wordDoc)
        Print "Spell checking Word document..."

    Method VisitPdfDocument(pdfDoc)
        Print "Spell checking PDF document..."

    Method VisitSpreadsheet(sheet)
        Print "Spell checking Spreadsheet..."

Class ExportToHTMLVisitor implements DocumentVisitor
    Method VisitWordDocument(wordDoc)
        Print "Exporting Word document to HTML..."

    Method VisitPdfDocument(pdfDoc)
        Print "Exporting PDF document to HTML..."

    Method VisitSpreadsheet(sheet)
        Print "Exporting Spreadsheet to HTML..."

//caller logic
documents = [new WordDocument(), new PdfDocument(), new Spreadsheet()]

spellChecker = new SpellCheckVisitor()
exporter = new ExportToHTMLVisitor()

For each doc in documents
    doc.Accept(spellChecker)

For each doc in documents
    doc.Accept(exporter)

In our Document Processor example above, think of each visitor as a specialist.

SpellCheckVisitor - knows how to spell check any document.
ExportToHTMLVisitor - knows how to export any document to HTML.

When a document receives a visitor, it simply hands itself over, and says,

“Here is my PDF data. You know what to do.”

This way, you keep document classes simple. You can add new operations anytime without touching existing document classes. With this, your code stays clean, flexible, and easy to grow.

What Did We Achieve?

No need to modify existing document classes when adding new operations.
Operations (Visitors) are separated from the document structure.
Adding a new visitor means adding new features without changing existing code.

When Should You Use Visitor Pattern?

When you have a stable set of classes (like document types) but frequently add new operations.
When you want to separate business logic from the object structure.
When you need to perform many unrelated operations on objects without mixing those operations into the objects themselves.

Use Cases?

Compilers: Different passes over syntax trees (type checking, optimization, code generation)
File explorers: Performing operations on different file types
Graphics editors: Applying different filters or transformations to shapes
E-commerce: Running promotions or discounts on different product categories

Is Visitor Confused with Any Other Pattern?

Yes. It is sometimes mistaken for the Strategy Pattern. Both separate behavior from objects, but here is the difference,
Strategy: Object decides which behavior to use.
Visitor: External entity visits and applies behavior to the object.

To summarize, it would be apt to say,

Visitor Pattern is like inviting a VIP guest who knows exactly what to do in each room, without asking you to renovate the building every time they visit.

It offers great flexibility for adding new operations while keeping your object structure intact.

Hope you got a clear understanding of the Visitor Pattern!

Next up: Proxy Pattern. Let's meet there!

Design Patterns Simplified: Part 14 — State Pattern (a.k.a. “The Mood Manager”)

Prateek Prabhakar — Fri, 08 Aug 2025 17:05:25 +0000

The State Pattern falls under the Behavioral category. Why? Because it deals with how an object behaves depending on its internal state and more importantly, how it can change that behavior dynamically at runtime.

Think of it like, when your object is in a “mood", its reactions depend on what mood it is currently in.

Let’s understand this with a story.

The Media Player

Imagine you are building a media player app with two main controls: a Play/Pause toggle button and a Stop button.

Sounds simple, right? But here’s the thing:

If the player is Stopped, pressing Play starts playback.
If it’s Playing, pressing Play pauses the music.
If it’s Paused, pressing Play resumes playback.
Pressing Stop at any point stops the music and resets the state.

The key insight is this,

The same Play button behaves differently depending on the current state of the player.

Without the State Pattern, you would be writing messy if-else chains to handle all scenarios.

With the State Pattern, each state (Playing, Paused, Stopped) handles user input its own way.

What Is the State Pattern?

The State Pattern allows an object to change its behavior when its internal state changes as if it changed its class.

Instead of managing the behavior using complex conditionals, the object delegates behavior to state specific classes.

What does the code look like?

To implement such behavior in the application, typically we would have the below components,

State Interface: declares the actions (Play, Pause, Stop).
Concrete State Classes: implement behavior specific to each state.
Context Class (MediaPlayer): maintains the current state reference and delegates action calls.

//Step 1: Define the State Interface
Interface PlayerState
    Method TogglePlayPause(player)
    Method Stop(player)

//Step 2: Define Concrete States
Class PlayingState implements PlayerState
    Method TogglePlayPause(player)
        Print "Pausing playback..."
        player.SetState(new PausedState())

    Method Stop(player)
        Print "Stopping playback..."
        player.SetState(new StoppedState())

Class PausedState implements PlayerState
    Method TogglePlayPause(player)
        Print "Resuming playback..."
        player.SetState(new PlayingState())

    Method Stop(player)
        Print "Stopping playback from pause..."
        player.SetState(new StoppedState())

Class StoppedState implements PlayerState
    Method TogglePlayPause(player)
        Print "Starting playback..."
        player.SetState(new PlayingState())

    Method Stop(player)
        Print "Already stopped."

//Step 3: Define the MediaPlayer Context
Class MediaPlayer
    Property currentState

    Constructor()
        currentState = new StoppedState()

    Method TogglePlayPause()
        currentState.TogglePlayPause(this)

    Method Stop()
        currentState.Stop(this)

//caller logic
player = new MediaPlayer()

player.TogglePlayPause()  // Starting playback...
player.TogglePlayPause()  // Pausing playback...
player.TogglePlayPause()  // Resuming playback...
player.Stop()             // Stopping playback...
player.Stop()             // Already stopped.

Each state class (PlayingState, PausedState, StoppedState) encapsulates the behavior for TogglePlayPause() and Stop() actions relevant to that state. The MediaPlayer object delegates these calls to its current state, allowing dynamic behavior changes without complex conditional logic.
This approach keeps the player’s behavior organized which is easy to extend and intuitive to manage.

What Did We Achieve?

No messy if-else chains: All state-specific behavior is encapsulated cleanly.
Easily extensible: Adding new states (like Buffering) means adding new classes and no modifications to existing code.
Cleaner MediaPlayer class: Just delegates actions. It has no complex logic.

When Should You Use State Pattern?

When an object’s behavior varies significantly depending on its state.
When complex conditional logic is hard to maintain and understand.
When you want to encapsulate each state’s logic for easier testing and modification.

Use Cases?

Media players (play/pause/stop)
Game characters (idle, running, jumping)
Vending machines (waiting for coin, dispensing, out of stock)
Traffic lights (green, yellow, red)
Network connections (connecting, connected, disconnected)
Workflow engines (draft, submitted, approved)

To summarize, it would be apt to say,

“State Pattern is like giving your object a brain that knows when and how to switch gears.”

It gives your objects a “mood” enabling them to behave differently based on their internal condition, without tangled conditional logic. This leads to cleaner, more maintainable code and makes extending behavior easier.

Next up in the series: Visitor Pattern. Let's understand that now!

BONUS: State vs Strategy — A Story to Remember

Imagine you are running a café that serves coffee.

Scenario 1: The Customer’s Mood (State Pattern)

One customer walks in. Depending on their mood - happy, tired, or grumpy, they order and react differently.

If they are happy, they smile and say, “I’ll have a cappuccino, please.”
If they are tired, they say, “Just a strong black coffee, thanks.”
If they are grumpy, they might say, “Make it quick, I’m in a hurry.”

The customer’s mood changes over time. After a sip, they might become happier or more relaxed, changing their behavior accordingly.

This is the State Pattern: the object (customer) changes behavior based on its internal state (mood).

Scenario 2: The Barista’s Tools (Strategy Pattern)
Now, the barista needs to prepare coffee. They can use different brewing methods - espresso machine, French press, or drip coffee maker.
The barista chooses the brewing method based on the customer’s preference or cafe’s style.

Each brewing method is an independent strategy i.e. a different algorithm to make coffee.
Here, the choice of brewing method comes from outside, the barista selects which strategy to use for the task.

This is the Strategy Pattern: The context (barista) uses a chosen strategy (brewing method) to accomplish a task.

The Key Difference:
State Pattern - The object itself controls which behavior to perform by switching between states internally.

Strategy Pattern - The client or context decides which algorithm or strategy to use externally and sticks with it.

Think of it like,

In State, the behavior changes because your mood changed.
In Strategy, the behavior changes because you picked a different tool.

Design Patterns Simplified: Part 13 — Template Method Pattern (a.k.a. “The Recipe Pattern”)

Prateek Prabhakar — Wed, 06 Aug 2025 12:51:43 +0000

The Template Method Pattern belongs to the Behavioral category of design patterns.

Why? Because it defines how an algorithm runs, step by step, while letting child classes tweak only the steps that vary.

Think of it like a cooking recipe. The steps are fixed,
Gather ingredients
Cook
Serve

But how you cook depends on the dish. You might make pasta or toss noodles, both follow the same structure(boil them first, put in the pan, etc.) but different steps.

The Template Method Pattern in a nutshell, is like the “recipe” your base class writes and subclasses just fill in the flavor.

What Is the Template Method Pattern?

The Template Method Pattern defines the skeleton of an algorithm in a base class, and lets subclasses override specific steps without changing the overall structure.

It helps,

Reuse shared logic
Keep algorithms consistent
Allow extensions via subclassing
Avoid code duplication

Report Generation System

Let’s say you are building an enterprise application that generates various types of reports like, Sales Report, Inventory Report, User Activity Report.

Every report follows the same high level process,

Connect to the database
Fetch relevant data
Format the data
Add a header and footer
Export to PDF

But the data and formatting vary based on report type.
Instead of repeating the full process in every report class, we define it once in a base class, and only override what is different.
That is the power of the Template Method Pattern.

What does the code look like?

The basic setup would involve the below 3 components.

Abstract class: defines the template (i.e. the fixed process)
Concrete subclasses: override the specific steps
Hook methods: optional steps that can be overridden if needed

//Step 1: Define the Template (Base Class)
Class ReportGenerator
    Method GenerateReport()
        ConnectToDatabase()    // Step 1: Common step
        FetchData()            // Step 2: Customized by subclass
        FormatData()           // Step 3: Customized by subclass
        AddHeader()            // Step 4: Common step
        AddFooter()            // Step 5: Common step
        Export()               // Step 6: Common step

    Method ConnectToDatabase()
        Print "Connecting to database..."

    // Variable steps
    Abstract Method FetchData()  // To be implemented by subclasses
    Abstract Method FormatData() // To be implemented by subclasses

    // Optional hooks
    Method AddHeader()
        Print "Adding standard header..."

    Method AddFooter()
        Print "Adding standard footer..."

    Method Export()
        Print "Exporting report to PDF..."

//Step 2: Define Concrete Reports
Class SalesReport extends ReportGenerator
    Method FetchData()
        Print "Fetching sales data for current month..."

    Method FormatData()
        Print "Creating bar chart for sales..."

Class InventoryReport extends ReportGenerator
    Method FetchData()
        Print "Fetching stock levels from warehouse DB..."

    Method FormatData()
        Print "Formatting inventory into table layout..."

//caller logic
report = new SalesReport()
report.GenerateReport()

// Output:
// Connecting to database...
// Fetching sales data for current month...
// Creating bar chart for sales...
// Adding standard header...
// Adding standard footer...
// Exporting report to PDF...

report = new InventoryReport()
report.GenerateReport()

// Output:
// Connecting to database...
// Fetching stock levels from warehouse DB...
// Formatting inventory into table layout...
// Adding standard header...
// Adding standard footer...
// Exporting report to PDF...

ReportGenerator is an abstract class that defines how a report should be generated, but not the specific details for every report.

The method GenerateReport() is the template method. This method is not meant to be overridden. It controls the flow. It outlines the exact sequence of steps to generate a report.

Connect to the database
Fetch data
Format the data
Add headers and footers
Export the final report

Steps like ConnectToDatabase(), AddHeader(), AddFooter(), and Export() are shared across all reports, so they are implemented once in the base class. AddHeader() and AddFooter() are basically hook methods that are optional steps the subclasses can override if they want to customize these parts, otherwise, the base implementation runs.

But steps like FetchData() and FormatData() may vary for each report type (Sales report vs. Inventory report), so they are declared as abstract methods. Subclasses must provide their own implementation.
This way, the base class ensures consistent structure, while subclasses customize the variable parts.

What Did We Achieve?

Consistent structure: All reports follow the same, tested process.
Flexible overrides: Customize only what’s necessary without changing the flow.
No code duplication: Common logic lives at one place in the base class.
Clear control: The base class owns the workflow and subclasses plug in their specifics.

When Should You Use It?

You have an algorithm with a fixed sequence of steps but some steps vary
You are building a framework or base class where extensions should follow a strict flow
You want to enforce consistency across subclasses while allowing custom behavior

Use Cases?

Report/document generation workflows
Unit test lifecycle (setup → test → teardown)
Order processing pipelines
File import/export processing
Game engine loops (initialize → update → render)
Image processing workflows (load → process → save)

To summarize, it would be apt to say,

The Template Method Pattern lets you define a fixed recipe, and delegate specific steps to child classes.
“It is the design pattern equivalent of a chef preparing a meal. The steps are fixed, but the ingredients vary.”

It gives your code Reusability, Structure and Controlled flexibility.

Next up in the series: State Pattern. Let's dive in!

BONUS: Isn't This Similar to Strategy Pattern?

At first glance, Template Method and Strategy Patterns may seem alike. Both let you vary parts of an algorithm. But the difference lies in who controls the flow.

Let us understand it through a quick story.

You work at a company that generates different types of reports -Sales, Inventory, Feedback (as we took the example in the article above). Your application requirements are as below,

All reports getting generated via this application must follow the same process.

Connect to DB

Fetch Data

Format Data

Add Header & Footer

Export to PDF

So, here the overall flow is fixed, but steps like data fetching and formatting differ per report type.
To implement this functionality, you create a base class ReportGenerator with a method GenerateReport() that defines this flow. Subclasses override the steps that vary.
That is Template Method Pattern.

What you are effectively saying is,

“This is how we have a fixed structure setup. You can tweak parts, but not the process.”

A week passes by and the product comes up with a new requirement,

“We want to export reports in different formats - PDF, Excel, or HTML depending on user preference.”

Now again, the flow stays the same, only the export format changes dynamically.

So you define a IReportExportStrategy interface and implement different export classes. You inject the appropriate strategy at runtime based on the configuration and send the report.
That is Strategy Pattern.

This time what you are saying is,

“The task stays the same. You choose the tool to do the final step.”

Differences:

To summarize the difference between the two, you should,

Use Template Method when the flow is fixed and only steps vary.
Use Strategy Pattern when the task is fixed but the way to perform it varies, and should be chosen at runtime.

Design Patterns Simplified: Part 12 — Memento Pattern (a.k.a. “Your Object's Time Machine”)

Prateek Prabhakar — Mon, 04 Aug 2025 12:19:00 +0000

The Memento Pattern belongs to the Behavioral category of design patterns.

Why? Because it focuses on how objects capture and restore their past states (like an Undo), all while keeping their internal details private.
It gives your application the power to,

Save a snapshot of an object’s state
Restore it to that state later
Do this all without exposing the object’s internal structure

It is like giving your object a Time Machine, so it can rewind to a known good state when things go wrong.

Let's take an example of the Shopping Cart Undo

Imagine you are shopping online,

You add a Phone to your cart.
Then a pair of Headphones.
Then a Charger.

Then suddenly, you accidentally delete the headphones from your cart. Oops! But no worries. You click ‘Undo’, and they are magically back.

That is the Memento Pattern in action.
Each time you make a change, your system quietly saves a snapshot of the cart.
When you click Undo, it just restores the last saved version.

What is the Momento Pattern?

It allows an object to capture and store its internal state so it can be restored later, all without exposing its internal details.

It involves 3 main parts,

Originator: The object whose state we want to save/restore (e.g. Shopping Cart)
Memento: A value object storing the Originator's state
Caretaker: Manages the history of Mementos, e.g. to allow undo/redo

Wiki Document with Version History

Let’s say you are editing a wiki document. You write, you revise, you delete, and eventually hit Publish.

Oops! You just realized you deleted an important paragraph. What would you do?
Mostly, you would like to revert it to a previous published version.

Each time you publish, the system silently saves the document’s current state. Later, you can roll back to any of those versions.

That is exactly what the Memento Pattern helps you do in code.

What does the code look like?

Say we want to mimic the code for how the wiki might be built with following features,

You can publish new versions
View current content
Undo to a previous version

//Step 1: Define the Memento (saved version of the document)
Class WikiMemento
    Constructor(content)
        this.content = content

    Method GetContent()
        return content

//Step 2: Define the Originator (Wiki Document)
Class WikiDocument
    Property content

    Method Write(text)
        content = text

    Method Show()
        Print("Current Content: " + content)

    Method Save()
        return new WikiMemento(content)

    Method Restore(memento)
        content = memento.GetContent()

//Step 3: Define the Caretaker (History Manager)
Class VersionHistory
    Property history = []

    Method SaveVersion(memento)
        history.Push(memento)

    Method Undo()
        If history is not empty:
            return history.Pop()
        Else:
            return null

//caller logic
// Initialize components
doc = new WikiDocument()
history = new VersionHistory()

// First version
doc.Write("Initial Draft of Wiki Page")
history.SaveVersion(doc.Save())

// Update version
doc.Write("Added introduction and summary")
history.SaveVersion(doc.Save())

// Another update
doc.Write("Removed summary by mistake...")
doc.Show()

// Undo last change
prev = history.Undo()
doc.Restore(prev)
doc.Show()

Just like hitting Undo in your document editor, your application brings back the last published version.

NOTE: In real world apps, you might want to undo to any specific version, not just the last one. This is also supported by the Memento Pattern but can add complexity. To keep things simple, here the example focuses on undoing the most recent change.

What Did We Achieve?

Internal state saved without exposing implementation
Clean separation between state management and history tracking
Reversible actions (Undo/Redo behavior)
It is scalable. You can add version limits, redo stacks, timestamps and more.

When Should You Use It?

When you want to implement undo/redo
When you need state checkpoints (e.g., autosave, game saves)
When you need to log or rollback user actions

Use Cases?

Document editors (Google Docs, Notion, MS Word)
Game save systems
State restoration in visual editors (like Figma, Canva)
Transaction rollback systems
Form editing with preview/reset options

To summarize, it would be apt to say,

The Memento Pattern lets your objects “remember” and "rewind" their states, just like a time machine, enabling undo functionality without exposing their inner workings.

It is the design pattern equivalent of Ctrl+Z. It gives you the power to undo mistakes or revisit past states without complicating your logic or breaking encapsulation.

Hope, the next time you hit the UNDO/REDO on your keyboard, you will definitely recall this pattern.

Next up in the series: Template Pattern. Join me there!