api: YAML JSON TOON Database version: 1.0.0 format: yaml dataset: id: 2781 slug: design-pattern-anti-patterns title: Software Anti-Patterns & Design Pattern Misuse description: Common software design anti-patterns, misuse of design patterns, code smells indicating trouble, and refactoring strategies to fix them. summary: "Common software anti-patterns and design-pattern misuse with aliases, symptoms, root cause, consequences, refactoring and related patterns: God Object, Singleton overuse, spaghetti code, golden hammer, premature optimization, copy-paste programming, lava flow and big ball of mud." use_when: - You are reviewing code or architecture for design problems. - You need the vocabulary for a code-review comment. caveats: - Labeling code with an anti-pattern name is a judgment; explain the concrete problem it causes. - Some anti-patterns are rational short-term choices under deadline pressure. related: - solid-principles - creational-patterns - behavioral-design-patterns - architectural-design-patterns entry_count: 8 fields: - section: anti_patterns field: name type: string example: God Object - section: anti_patterns field: also_known_as type: string example: Blob, Cosmic Know-It-All - section: anti_patterns field: symptoms type: array example: "[4 items]" - section: anti_patterns field: root_cause type: string example: Failure to decompose domain logic, premature op… - section: anti_patterns field: consequences type: array example: "[4 items]" - section: anti_patterns field: refactoring type: string example: Identify cohesive groups of methods → Extract C… - section: anti_patterns field: related_patterns type: string example: Facade (bad when used to wrap a God Object inst… - section: anti_patterns field: when_genuinely_needed type: string example: Logging framework, configuration manager (immut… - section: anti_patterns field: prevention type: string example: "Enforce cyclomatic complexity limits (CI gate: …" - section: anti_patterns field: examples type: string example: Using microservices for a 3-page website, Event… - section: anti_patterns field: healthy_approach type: string example: Design reasonable architecture upfront, impleme… category: Design Patterns category_slug: design-patterns tags: anti-patterns,code-smells,refactoring,software-design,bad-practices,technical-debt view_count: 40 created_at: 1777673262 updated_at: 1777673262 data: anti_patterns: - name: God Object also_known_as: Blob, Cosmic Know-It-All symptoms: - Single class with thousands of lines - Class has more than 10-15 methods - Class references dozens of unrelated types - Every new feature touches this class first root_cause: Failure to decompose domain logic, premature optimization centralization, or gradual feature creep without refactoring. consequences: - Impossible to unit test effectively - Merge conflicts on every change - Single point of failure - Developer onboarding nightmare refactoring: Identify cohesive groups of methods → Extract Class for each group → Extract Interface for contracts → Use Facade pattern to simplify API if needed → Apply Dependency Injection to decouple related_patterns: Facade (bad when used to wrap a God Object instead of fixing it) - name: Singleton Overuse (Singletonitis) symptoms: - Half the classes in project are Singletons - Global mutable state everywhere - Unit tests require complex setup or ordering - "\"Just make it a Singleton\" is common team response" root_cause: Convenience of global access mistaken for good design, misunderstanding of when shared state is truly needed. consequences: - Hidden coupling between seemingly unrelated code - Testing requires shared state cleanup between tests - Race conditions in multithreaded environments - Hard to swap implementations refactoring: Replace Singleton with Dependency Injection → Inject dependencies via constructor → For truly single-instance needs, use DI container's singleton scope → Avoid global state accessor pattern when_genuinely_needed: Logging framework, configuration manager (immutable after load), hardware interface (OS has one instance), thread pool manager - name: Spaghetti Code symptoms: - Methods longer than 50 lines with nested control structures - GOTO or excessive break/continue usage - Global variables modified everywhere - No clear layer separation - Copy-paste code duplication root_cause: Lack of design, deadline pressure, insufficient refactoring, or working in a language without structured programming support. consequences: - Extreme maintenance cost - Bug introduction rate proportional to change size - Almost impossible to test - Developer attrition from frustration refactoring: Extract Method religiously (every 5-10 lines) → Replace Conditionals with Strategy Pattern → Introduce layered architecture → Remove global state → Add unit tests as safety net during refactoring prevention: "Enforce cyclomatic complexity limits (CI gate: < 10 per method), mandatory code reviews, pair programming for complex features" - name: Golden Hammer also_known_as: "Law of Instrument (\"If all you have is a hammer, everything looks like a nail\")" symptoms: - Same technology/solution used for every problem - Forcing a pattern where it doesn't fit - Team dismisses alternatives without evaluation - Massive complexity from using wrong tool root_cause: Team comfort zone, resume-driven development, over-generalization of past success, lack of diverse technical exposure. consequences: - Over-engineered solutions for simple problems - Poor performance from inappropriate architecture - Hard to find/onboard developers for niche stack refactoring: Evaluate each problem independently → Document trade-off decisions → Use polyglot approach where justified → Invest in team technical diversity examples: Using microservices for a 3-page website, Event Sourcing for a CRUD app, Machine Learning when a simple rule suffices - name: Premature Optimization symptoms: - Complex caching layers before performance is measured - Hand-rolled data structures when built-in works - Micro-optimizations in early development stages - "\"This might be slow\" comments everywhere" root_cause: "Misapplication of \"performance mindset\", lack of profiling data, assumption-driven development." consequences: - Unnecessary code complexity - Introduces bugs in unmeasured code paths - "Wasted development time (Pareto: 20% of code causes 80% of perf issues)" - Harder to refactor later refactoring: "Profile first, optimize second → Remove speculative complexity → Measure before/after → Apply Knuth's maxim: \"Premature optimization is the root of all evil\"" healthy_approach: Design reasonable architecture upfront, implement simply, profile in production, optimize only measured bottlenecks - name: Copy-Paste Programming symptoms: - Identical code blocks in multiple locations - Bug fix applied in one place but not another - "\"Variations\" of same function with minor changes" - Codebase size grows faster than feature count root_cause: Deadline pressure, laziness, lack of refactoring culture, inadequate code review, absence of abstraction skills. consequences: - Bug fix multiplication (fix in N places) - Inconsistent behavior across duplicated blocks - Code review bloat - Technical debt snowball refactoring: Extract Method/Class for each duplicate → Parameterize variations → Template Method pattern for similar algorithms → Use code duplication detection tools (Simian, PMD-CPD) prevention: CI gate with duplication threshold, code review requirement, pair programming for complex logic - name: Lava Flow symptoms: - Dead code that no one understands - Commented-out code blocks - "\"TODO: remove this after testing\" lasting months" - Code paths that no longer execute but are maintained - "\"Don't touch that, it might break something\"" root_cause: Rapid prototyping without cleanup, developer turnover without knowledge transfer, fear of removing unknown code. consequences: - Increased maintenance burden - Confusion during debugging (which code actually runs?) - Binary size bloat - Dead code deceives readers about actual behavior refactoring: Systematically identify dead code via code coverage tools → Remove confirmed dead code → Add tests for live code → Use version control history as safety net prevention: Regular codebase cleanup sprints, enforce code coverage minimums, remove features entirely when deprecated - name: Big Ball of Mud symptoms: - No clear architecture or layering - Every module depends on every other module - No separation of concerns - "\"Just import it directly\" is standard practice" - Change in one place breaks unrelated areas root_cause: "Organic growth without architectural oversight, no refactoring, short-term thinking, \"just make it work\" culture." consequences: - Extreme fragility (butterfly effect bugs) - Cannot estimate feature development time - 100% regression testing needed for every change - Eventual rewrite (which will become another BBoM) refactoring: Strangler Fig pattern → Identify bounded contexts → Extract modules one by one → Define clear interfaces between modules → Add architectural tests to enforce boundaries prevention: Architecture Decision Records (ADRs), architectural fitness functions, regular architecture reviews, CI-enforced module boundaries