Anti-pattern — a common solution that looks right but causes harm

Definition

An anti-pattern is a commonly used solution to a recurring problem that appears reasonable but consistently produces negative consequences. Anti-patterns are named and documented precisely because their harm is non-obvious — they look like solutions, which is what makes them dangerous. The term was coined by Andrew Koenig in 1995 and popularized by the book "AntiPatterns" (Brown et al., 1998).

In Practice

<?php
// Anti-pattern: God Class / Fat Model
// Looks like good OOP organization at first glance.
// In reality it violates SRP and becomes unmaintainable.
class User extends Model
{
    // Data access
    public function scopeActive($query) { /* ... */ }

    // Business logic (should be in a service)
    public function calculateSubscriptionPrice(): Money { /* ... */ }

    // Formatting (should be in a presenter/resource)
    public function formattedAddress(): string { /* ... */ }

    // Third-party integration (should be in a service)
    public function syncToMailchimp(): void { /* ... */ }

    // Authorization (should be in a Policy)
    public function canDownloadInvoice(User $viewer): bool { /* ... */ }
}

// The fix: distribute responsibilities to appropriate classes
class SubscriptionPricingService { /* ... */ }
class UserPresenter { /* ... */ }
class MailchimpSyncService { /* ... */ }
class UserPolicy { /* ... */ }

Common PHP/Laravel anti-patterns include: the God Class (fat Eloquent models), the Service Locator used instead of dependency injection (app()->make() scattered through business logic), the Anemic Domain Model (models with no behaviour, all logic in services), and Primitive Obsession (passing raw strings and integers instead of typed value objects like Money, Email, or UserId).

In Context

Knowing anti-pattern names gives you precise vocabulary in code reviews and interviews. Instead of saying "this class does too much", you say "this is a God Class — it violates SRP and will become a coordination bottleneck as the team grows." Pattern vocabulary signals seniority.

The distinction between a pattern and an anti-pattern is context-dependent. The Singleton is a legitimate design pattern in some contexts (the service container itself) and an anti-pattern in others (a global mutable state bag shared across tests). This is why the definition includes "consistently produces negative consequences" — it's the track record, not the structure, that earns the label.

Related terms: design pattern (the positive counterpart — proven solutions to recurring problems), code smell (a symptom in the code that hints at a deeper structural problem, often pointing to an anti-pattern), refactoring (the activity of eliminating anti-patterns), and technical debt (anti-patterns accumulate as technical debt over time).