15. Observer Pattern | Engineering Notes

🧠 Observer Pattern

The Observer Pattern allows you to listen to model events and automatically trigger actions.

👉 Instead of scattering logic, you centralize side effects in one place.

🎯 Simple Idea

plain text

Event happens (e.g., User created)
 ↓
Observer listens
 ↓
Observer executes logic

👉 “When something happens → trigger related actions”

🧩 Laravel Example (Model Observer)

Common use cases:

plain text

User created → send welcome email
User updated → log activity
User deleted → cleanup related data

🧱 Example

Observer Class

plain text

class UserObserver
{
    public function created(User $user)
    {
        // send email
    }

    public function updated(User $user)
    {
        // log activity
    }

    public function deleted(User $user)
    {
        // cleanup
    }
}

Register Observer

plain text

User::observe(UserObserver::class);

📌 Flow

plain text

Model action (create/update/delete)
 ↓
Laravel triggers event
 ↓
Observer listens
 ↓
Observer handles side effects

🧠 What I Use It For

sending notifications (email, SMS, etc.)

logging or auditing changes

triggering background jobs

maintaining related data consistency

cache updates (e.g., clear or refresh when data changes)

⚖️ Trade-offs

logic is less visible (can be harder to trace)

debugging can be slightly harder

overuse can lead to hidden complexity

📌 Practical Rule

plain text

Use Observer for simple side effects triggered by model events

Examples:

plain text

User created → send email
Order updated → update status log
Model changed → clear related cache

🚫 When NOT to Use

complex workflows → use Service Layer

multi-step business logic

cases needing strict execution control

💬 Summary

> I use the Observer Pattern to handle side effects like notifications, logging, and minor data consistency tasks when model events occur.

plain text

Model Event
→ Observer
→ Execute side-effect logic

👉 This keeps the system clean, decoupled, and maintainable 🚀