Yazılım projeleri, özellikle zaman baskısı ve sürekli değişen gereksinimler altında geliştirildiğinde, çoğu zaman "şimdilik çalışsın yeter" mantığıyla ilerler. Bu yaklaşım kısa vadede işleri hızlandırıyor gibi görünse de, uzun vadede kod tabanında ciddi yapısal sorunlara yol açar. İşte bu sorunlardan biri de God Class olarak bilinen anti-pattern’dir.

God Class, nesne yönelimli programlamada bir sınıfın aşırı fazla sorumluluk üstlenmesi durumudur. Yani bu sınıf, sistemin farklı katmanlarına ait işleri kendi içinde toplamış, adeta "her şeyi bilen ve yapan" bir yapıya bürünmüştür. İsmindeki “God” (Tanrı) ifadesi de buradan gelir: bu sınıf sistemdeki neredeyse her şeye dokunur, kontrol eder ve yönetir.

Adından da anlaşılacağı gibi, bu sınıf:

• Çok büyük ve karmaşık olur

• Çok sayıda metoda sahiptir

• Diğer sınıflara fazla bağımlıdır

• Sistemdeki pek çok modülün kontrolünü elinde tutar

📌 Kısaca: God Class = Single Responsibility Principle (SRP) ihlali. 

God Class'ın Belirtileri

God Class’ı kod tabanında tespit etmek için şu işaretlere dikkat edebilirsiniz:

1. Aşırı Uzun Sınıf

   • 1000+ satır kod

   • Onlarca property ve method

2. Fazla Bağımlılık

   • 5’ten fazla farklı sınıfı doğrudan kullanıyor

   • Çok fazla “using” ifadesi

3. Çok Fazla Sorumluluk

   • Veritabanı işlemleri yapıyor

   • UI güncelliyor

   • İş mantığını yönetiyor

   • Loglama yapıyor

4. Kod Tekrarı ve Karmaşık Bağımlılıklar

   • Birçok metotta benzer kod blokları

   • Sınıfın test edilmesi zor

God Class Örneği (C#)

📌 Aşağıdaki sınıf tipik bir God Class örneğidir:

public class OrderManager
{
    private readonly Database _database;
    private readonly EmailService _emailService;
    private readonly PaymentGateway _paymentGateway;

    public OrderManager(Database database, EmailService emailService, PaymentGateway paymentGateway)
    {
        _database = database;
        _emailService = emailService;
        _paymentGateway = paymentGateway;
    }

    public void CreateOrder(Order order)
    {
        // Validate order
        if (string.IsNullOrWhiteSpace(order.CustomerEmail))
            throw new Exception("Invalid email");

        // Process payment
        if (!_paymentGateway.Charge(order))
            throw new Exception("Payment failed");

        // Save to DB
        _database.Save(order);

        // Send confirmation email
        _emailService.Send(order.CustomerEmail, "Order Confirmed");
    }

    public void CancelOrder(int orderId)
    {
        var order = _database.GetOrder(orderId);
        if (order == null)
            throw new Exception("Order not found");

        // Refund payment
        _paymentGateway.Refund(order);

        // Update DB
        _database.Delete(order);

        // Send cancellation email
        _emailService.Send(order.CustomerEmail, "Order Cancelled");
    }

    public List<Order> GetAllOrders()
    {
        return _database.GetAllOrders();
    }

    public void GenerateReport()
    {
        var orders = _database.GetAllOrders();
        // Some complex report logic here
    }
}

💥 Sorunlar:

• OrderManager hem ödeme, hem e-posta, hem veritabanı hem de raporlama yapıyor.

• Test etmek zor çünkü birçok bağımlılık var.

• SRP (Single Responsibility Principle) tamamen ihlal edilmiş.

God Class'ın Zararları

1. Bakım Zorluğu

   • Küçük bir değişiklik bile tüm sınıfı etkileyebilir.

2. Test Zorluğu

   • Mock ve stub kullanımı karmaşıklaşır.

3. Kod Tekrarı ve Bağımlılık Karmaşası

   • Aynı iş mantığı birden fazla yerde bulunabilir.

4. Düşük Modülerlik

   • Diğer sistemlere kolay adapte edilemez.

God Class’ı Tespit Etme Yöntemleri

• Statik Kod Analizi

  • SonarQube, ReSharper, PMD gibi araçlar

  • “Class too large” uyarıları

• Kod Kokusu (Code Smell) Listeleri

  • Çok fazla satır sayısı

  • Çok fazla metot

  • Bağımlılık enflasyonu

God Class’tan Nasıl Kurtuluruz? (Refactoring)

📌 Adım 1: Sorumlulukları Belirle
Örneğimizde OrderManager’ın şu sorumlulukları var:

1. Sipariş yönetimi

2. Ödeme işlemleri

3. E-posta gönderme

4. Raporlama

📌 Adım 2: Yeni Sınıflar Oluştur
Her sorumluluk ayrı sınıfa taşınmalı.

📌 Adım 3: Bağımlılıkları Enjekte Et (Dependency Injection)
OrderService, PaymentService, NotificationService gibi sınıflar oluştur.

Refactored Kod Örneği

public class OrderService
{
    private readonly PaymentService _paymentService;
    private readonly NotificationService _notificationService;
    private readonly OrderRepository _orderRepository;

    public OrderService(PaymentService paymentService, NotificationService notificationService, OrderRepository orderRepository)
    {
        _paymentService = paymentService;
        _notificationService = notificationService;
        _orderRepository = orderRepository;
    }

    public void CreateOrder(Order order)
    {
        _paymentService.ProcessPayment(order);
        _orderRepository.Save(order);
        _notificationService.SendOrderConfirmation(order.CustomerEmail);
    }

    public void CancelOrder(int orderId)
    {
        var order = _orderRepository.GetOrder(orderId);
        _paymentService.RefundPayment(order);
        _orderRepository.Delete(order);
        _notificationService.SendOrderCancellation(order.CustomerEmail);
    }
}

Artık:

• Her sınıf tek bir sorumluluğa odaklanıyor.

• Kod daha okunabilir ve test edilebilir.

AI ile God Class Refactoring

Cursor, ChatGPT, GitHub Copilot gibi AI araçları God Class tespitinde çok etkili olabilir:

• Kodun uzunluğunu ve bağımlılık sayısını analiz eder

• SRP ihlallerini raporlar

• Parçalara ayırma önerileri sunar

📌 Cursor Prompt Örneği:

“Analyze this class and suggest a refactoring that follows the Single Responsibility Principle.”

Sonuç: AI, sınıfı farklı servislere bölmenizi önerir ve hatta direkt kodu üretebilir.

Sonuç

God Class, yazılımın gizli teknik borçlarından biridir. İlk başta pratik gibi görünse de, uzun vadede bakım kabusuna dönüşür. Çözüm: SRP’yi benimseyerek sınıfları küçük, modüler ve bağımsız tutmak. AI destekli araçlar bu süreci hızlandırabilir ve daha güvenli hale getirebilir.