{ "api": "YAML JSON TOON Database", "version": "1.0.0", "format": "json", "dataset": { "id": 47, "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" ], "category": "Design Patterns", "category_slug": "design-patterns", "tags": "anti-patterns,code-smells,refactoring,software-design,bad-practices,technical-debt", "view_count": 0, "created_at": 1777673262, "updated_at": 1777673262, "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…" } ] }, "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" } ] } }