README.md

God Objects - The Anti-Pattern

The Problem

A "God Object" does everything:

• Impossible to understand - 1000+ lines, 50+ methods
• Impossible to test - Too many dependencies
• Impossible to maintain - Changes break everything
• Violates Single Responsibility - Does database, email, SEO, images...

Bad Practice

class PostManager {
    // Does EVERYTHING!
    public function create_post() { }
    public function validate_title() { }
    public function send_email() { }
    public function generate_seo() { }
    public function upload_image() { }
    public function share_to_facebook() { }
    public function export_to_pdf() { }
    public function cache_post() { }
    // ... 50 more methods
}

Problems:

• 1000+ lines of code
• Knows about database, email, images, SEO, social media
• Can't test individual features
• Changes to SEO affect email notifications
• Multiple developers can't work on it

Good Practice

Break into focused classes:

// Each class has ONE responsibility

class PostRepository {
    // Database only
    public function find($id) { }
    public function create($data) { }
}

class PostValidator {
    // Validation only
    public function validate($data) { }
}

class PostNotifier {
    // Email only
    public function notify_new_post($id) { }
}

class PostSEO {
    // SEO only
    public function generate_meta($post) { }
}

// Service orchestrates
class PostService {
    public function __construct(
        private PostRepository $repo,
        private PostValidator $validator,
        private PostNotifier $notifier
    ) {}
    
    public function create_post($data) {
        $this->validator->validate($data);
        $id = $this->repo->create($data);
        $this->notifier->notify_new_post($id);
        return $id;
    }
}

Single Responsibility Principle

Each class should have ONE reason to change:

• PostRepository changes when database structure changes
• PostValidator changes when validation rules change
• PostNotifier changes when email templates change
• PostSEO changes when SEO requirements change

Changing SEO doesn't affect email!

Benefits

✅ Easy to understand - Small, focused classes ✅ Easy to test - Mock dependencies ✅ Easy to modify - Change one thing ✅ Easy to reuse - Compose as needed ✅ Team-friendly - Multiple developers can work simultaneously

How to Fix God Objects

1. Identify responsibilities - What does it do?
2. Group related methods - Database, validation, email...
3. Extract classes - One class per responsibility
4. Inject dependencies - Pass in what's needed
5. Test independently - Each class testable

Warning Signs

🚨 Class has 500+ lines
🚨 Class has 20+ methods
🚨 Class name is vague ("Manager", "Handler", "Utility")
🚨 Methods do unrelated things
🚨 Hard to write tests
🚨 Changes break unrelated features

Key Takeaways

✅ One class = one responsibility
✅ Small, focused classes
✅ Compose via dependency injection
✅ Each class easy to test
✅ Each class easy to understand

❌ Don't create God Objects
❌ Don't put everything in one class
❌ Don't mix unrelated concerns
❌ Don't make classes do "everything"

The Bottom Line

God Objects are the path to unmaintainable code.

Break them into focused classes following Single Responsibility Principle.

Your code will be:

• Easier to understand
• Easier to test
• Easier to modify
• Easier for teams to work on

One class, one job, done well.