api: YAML JSON TOON Database
version: 1.0.0
format: toon
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[2]: You are reviewing code or architecture for design problems.,You need the vocabulary for a code-review comment.
  caveats[2]: 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[4]: solid-principles,creational-patterns,behavioral-design-patterns,architectural-design-patterns
  entry_count: 8
  fields[11]{section,field,type,example}:
    anti_patterns,name,string,God Object
    anti_patterns,also_known_as,string,"Blob, Cosmic Know-It-All"
    anti_patterns,symptoms,array,"[4 items]"
    anti_patterns,root_cause,string,"Failure to decompose domain logic, premature op…"
    anti_patterns,consequences,array,"[4 items]"
    anti_patterns,refactoring,string,Identify cohesive groups of methods → Extract C…
    anti_patterns,related_patterns,string,Facade (bad when used to wrap a God Object inst…
    anti_patterns,when_genuinely_needed,string,"Logging framework, configuration manager (immut…"
    anti_patterns,prevention,string,"Enforce cyclomatic complexity limits (CI gate: …"
    anti_patterns,examples,string,"Using microservices for a 3-page website, Event…"
    anti_patterns,healthy_approach,string,"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: 41
  created_at: 1777673262
  updated_at: 1777673262
data:
  anti_patterns[8]:
    - name: God Object
      also_known_as: "Blob, Cosmic Know-It-All"
      symptoms[4]: 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[4]: 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[4]: 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[4]: 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[5]: 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[4]: 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[4]: 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[3]: 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[4]: 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[4]: 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[4]: 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[4]: 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[5]: 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[4]: 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[5]: 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[4]: 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"