Mahmoud Abas, Full-Stack Software Engineer & AI

System Design & Design Patterns - Anti-Patterns: What NOT to Do

In the print dialog, choose "Save as PDF" as the destination.

Anti-Patterns: What NOT to Do

Common Traps When Applying Design Patterns

What Are Anti-Patterns?

Common responses to recurring problems that are usually ineffective
Counterproductive despite looking like a reasonable solution
Understanding them is as important as knowing the patterns themselves

Anti-Patterns Taxonomy

Anti-Patterns

Misuse of Patterns

Golden Hammer, Pattern Obsession, Copy-Paste Programming

Architectural Anti-Patterns

Big Ball of Mud, Spaghetti Code, God Object

Code-Level Anti-Patterns

Magic Numbers, Dead Code, Duplicate Code

Singleton Abuse

The Problem

Everything becomes a singleton: Config, Database, Log managers
Creates hidden global state throughout the app
Makes unit testing difficult, state leaks between tests
Causes tight coupling between unrelated components

Singleton Abuse

The Fix

python

class OrderService:
    def __init__(self, config, db, logger):
        self.config = config
        self.db = db
        self.logger = logger

    def process_order(self, order):
        # use injected dependencies
        pass

Dependency injection instead of global singletons

God Factory

The Problem

One factory handles every type, subtype, and variant
Deeply nested if/elif chains for each combination
100+ lines of creation logic crammed into one class
Violates Single Responsibility, the factory does too much

God Factory

The Fix

python

class UserFactory:
    def create_admin(self, level): pass
    def create_regular_user(self): pass

class ProductFactory:
    def create_physical_product(self): pass
    def create_digital_product(self): pass

Specialized factories instead of one God Factory

The God Object

God Object: One class that handles processUser, handlePayment, sendEmail, validateData, generateReport, and dozens more methods.

Violates the Single Responsibility Principle
Impossible to test, reuse, or reason about in isolation

Big Ball of Mud

No clear structure or separation of concerns
Codebase evolves without a coherent architectural vision
Modules tangle into circular, criss-crossing dependencies
Becomes increasingly hard to understand, maintain, and extend

Magic Numbers and Strings

Unexplained literals like 0.15 or code == 1 scattered through logic
Readers can't tell what the value actually means
Fix: extract into named constants, for example PREMIUM_RATE = 0.15
Named constants document intent directly in the code

Copy-Paste Programming

Near-identical email or notification functions repeated per event type
Any change must be made in every single copy
Fix: a Template Method pattern to share the common flow
One shared method, with only the varying parts overridden

Anti-Pattern Detection Checklist

Class over 500 lines?

yes: possible God Object

Method over 50 lines?

yes: extract methods

Duplicate code?

yes: apply the DRY principle

Magic numbers?

yes: extract named constants

Tight coupling?

yes: apply SOLID principles

Anti-Pattern Prevention Guidelines

Single Responsibility, each class should have one reason to change
Avoid global state, minimize singletons and global variables
Favor composition and dependency injection over inheritance
Keep it simple, don't over-engineer solutions
Refactor regularly, review code, and test early to catch design issues

Key Takeaways

Anti-patterns are seductive shortcuts that create long-term pain
Singleton abuse and God Factories both stem from ignoring Single Responsibility
Magic numbers and copy-pasted code quietly rot a codebase over time
Use the detection checklist during code review to catch these early
Prevention beats refactoring: keep classes small, favor composition, test early

Open this lesson

Mahmoud AbasAnti-Patterns: What NOT to Do

class OrderService: def __init__(self, config, db, logger): self.config = config self.db = db self.logger = logger def process_order(self, order): # use injected dependencies pass

class UserFactory: def create_admin(self, level): pass def create_regular_user(self): pass class ProductFactory: def create_physical_product(self): pass def create_digital_product(self): pass