What Anti-Patterns Do You Know?

Junior Level

Anti-patterns are bad solutions that are frequently repeated. They look like patterns but harm rather than help.

Common anti-patterns:

1. God Object:

// One class does EVERYTHING
public class Application {
    public void connectToDatabase() { }
    public void validateUser() { }
    public void sendEmail() { }
    public void generateReport() { }
    public void backupData() { }
    // ... another 1000 methods
}

2. Spaghetti Code:

// Code without structure, hard to read
public void process() {
    if (a) { for (...) { if (b) { ... } } }
    else { while (...) { switch (...) { ... } } }
}

3. Copy-Paste Programming:

// Same code in 10 places
// Changed in one — forgot in the rest

How to avoid:

Split code into small classes
Follow SOLID principles
Don’t copy code — use shared methods

Middle Level

Main Anti-Patterns

1. Golden Hammer:

// Using a favorite pattern everywhere possible
// "I have Spring — I'll make everything through beans!"
// Sometimes a simple if-else is enough

2. Inner-Platform Effect:

// Reinventing the wheel inside the application
// Custom DB on top of file system
// Custom ORM on top of JDBC

3. Lava Flow:

// Code nobody understands but is afraid to delete
// "Don't touch, it works"
// -> Technical debt grows

4. Magic Push Button:

// Using code without understanding how it works
// Copy-paste from StackOverflow
// -> Bugs impossible to debug

5. Poltergeist:

// Stateless classes that only call other classes
public class Manager {
    public void doWork() {
        service.process(new Processor().execute());
    }
}
// -> Excessive level of indirection

How to Recognize

Sign	Anti-Pattern
Class > 500 lines	God Object
Method > 50 lines	Long Method
10+ parameters	Parameter List
Code duplication	Copy-Paste
“Don’t touch, works”	Lava Flow

Senior Level

Architectural Anti-Patterns

1. Big Ball of Mud:

No architecture, everything connected to everything
-> Change in one place breaks another
-> Impossible to test
-> Solution: refactoring, modularization

2. Architecture by Implosion:

Designing from details to general
-> Started coding without design
-> Lost the big picture

3. Cargo Cult Programming:

// Copying code/configuration without understanding why.
// For example, adding @Transactional to every method "just in case".
// Or adding @Service to every class "because that's the convention".

4. Not Invented Here:

"Ours is better" -> rewriting everything from scratch
-> Spending years on what's already done

Organizational Anti-Patterns

1. Design by Committee:

Too many people making decisions
-> Compromise, suboptimal design
-> "A camel is a horse designed by a committee"

2. Management by Numbers:

Evaluation by metrics only
-> Ignoring code quality
-> Technical debt grows

Code Anti-Patterns

1. Couplet:

// Tight coupling of two classes
class A { private B b = new B(); }
class B { private A a = new A(); }
// -> Circular dependency

2. God Object (aka Blob):

One class does everything, others — only pass data
-> SRP violation
-> Solution: responsibility distribution

3. Sequential Coupling:

// Methods must be called in strict order
obj.init();
obj.configure();
obj.process();  // If called without init -> exception!
// -> Solution: Builder or constructor

Prevention Strategies

Code Review — catch anti-patterns before merge
Static Analysis — SonarQube, Checkstyle
Metrics — track complexity, duplication
Refactoring — regularly clean code
Knowledge Sharing — teach the team

Production Experience

Real scenario: God Object killed the project

UserService class: 5000 lines, 200 methods
15 developers working concurrently -> merge conflicts every day
Solution: split into 12 classes by SRP
Result: conflicts disappeared, readability significantly improved

Best Practices

SOLID — best defense against anti-patterns
KISS — don’t overcomplicate
YAGNI — don’t build “for the future”
DRY — don’t copy code
Code Review — collective responsibility
Refactoring — regular cleanup
Metrics — measure quality

Senior Summary

Anti-patterns = repeated bad solutions
God Object — most common in enterprise
Lava Flow — sign of missing Code Review
Golden Hammer — pattern abuse
Big Ball of Mud — no architecture
SOLID — best prevention
Metrics — early problem detection
Refactoring — regular code hygiene

Interview Cheat Sheet

Must know:

God Object — one class does everything (>500 lines, >200 methods), violates SRP, solution: split by responsibility
Golden Hammer — using a favorite pattern everywhere, overengineering kills readability
Lava Flow — code nobody understands but is afraid to delete -> technical debt grows
Big Ball of Mud — no architecture, everything connected to everything, impossible to test
Cargo Cult — copying code/configuration without understanding (@Transactional on every method “just in case”)
Poltergeist — stateless classes that only call other classes -> excessive indirection
SOLID + KISS + YAGNI + DRY — best anti-pattern prevention

Common follow-up questions:

How to recognize a God Object? — Class >500 lines, >200 methods, 15+ developers concurrently -> merge conflicts
What is Lava Flow and why is it dangerous? — “Don’t touch, it works” -> nobody understands the code -> technical debt grows
How does Cargo Cult differ from Golden Hammer? — Cargo Cult = copying without understanding, Golden Hammer = pattern abuse
How to fight Big Ball of Mud? — Modularization, Code Review, Static Analysis (SonarQube), regular refactoring

Red flags (DO NOT say):

“We have one class for the entire service” — that’s a God Object, SRP split is mandatory
“I add @Transactional everywhere for safety” — Cargo Cult, unnecessary overhead
“This code is old but works — don’t touch it” — Lava Flow, source of bugs
“I don’t need code quality metrics” — without metrics, anti-patterns grow unnoticed

Related topics:

[[01. What are design patterns]] — patterns vs anti-patterns
[[03. What is Singleton]] — Singleton as a source of anti-patterns
[[06. What are problems with Singleton]] — Singleton problems
[[02. What pattern categories exist]] — proper patterns instead of anti-patterns
[[12. Advantage of Decorator over inheritance]] — composition as an alternative to God Object