{ "api": "YAML JSON TOON Database", "version": "1.0.0", "format": "json", "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\u2026" }, { "section": "anti_patterns", "field": "consequences", "type": "array", "example": "[4 items]" }, { "section": "anti_patterns", "field": "refactoring", "type": "string", "example": "Identify cohesive groups of methods \u2192 Extract C\u2026" }, { "section": "anti_patterns", "field": "related_patterns", "type": "string", "example": "Facade (bad when used to wrap a God Object inst\u2026" }, { "section": "anti_patterns", "field": "when_genuinely_needed", "type": "string", "example": "Logging framework, configuration manager (immut\u2026" }, { "section": "anti_patterns", "field": "prevention", "type": "string", "example": "Enforce cyclomatic complexity limits (CI gate: \u2026" }, { "section": "anti_patterns", "field": "examples", "type": "string", "example": "Using microservices for a 3-page website, Event\u2026" }, { "section": "anti_patterns", "field": "healthy_approach", "type": "string", "example": "Design reasonable architecture upfront, impleme\u2026" } ], "category": "Design Patterns", "category_slug": "design-patterns", "tags": "anti-patterns,code-smells,refactoring,software-design,bad-practices,technical-debt", "view_count": 42, "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 \u2192 Extract Class for each group \u2192 Extract Interface for contracts \u2192 Use Facade pattern to simplify API if needed \u2192 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 \u2192 Inject dependencies via constructor \u2192 For truly single-instance needs, use DI container's singleton scope \u2192 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) \u2192 Replace Conditionals with Strategy Pattern \u2192 Introduce layered architecture \u2192 Remove global state \u2192 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 \u2192 Document trade-off decisions \u2192 Use polyglot approach where justified \u2192 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 \u2192 Remove speculative complexity \u2192 Measure before\/after \u2192 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 \u2192 Parameterize variations \u2192 Template Method pattern for similar algorithms \u2192 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 \u2192 Remove confirmed dead code \u2192 Add tests for live code \u2192 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 \u2192 Identify bounded contexts \u2192 Extract modules one by one \u2192 Define clear interfaces between modules \u2192 Add architectural tests to enforce boundaries", "prevention": "Architecture Decision Records (ADRs), architectural fitness functions, regular architecture reviews, CI-enforced module boundaries" } ] } }