Tek Sorumluluk İlkesi ile Monolitleri Yeniden Yapılandırma

Miras sistemler, çok fazla endişeyle uğraşan şişkin sınıflardan muzdarip olur. Bu "Tanrı Nesnesi" anti-deseni, kodu test etmeyi, bakımını yapmayı ve genişletmeyi zorlaştırır. Tek Sorumluluk İlkesi'ni (SRP) uygulayarak, bu monolitik servisleri tüm sistemi yeniden yazmadan daha küçük, odaklı birimlere bölebiliriz. Bu rehber, üretim ortamlarında SRP'yi uygulama için pratik bir yol haritası sunar.

Sorumluluk İhlallerini Belirleme

İlk adım, SRP'nin nerede ihlal edildiğini belirlemektir. Bir sınıfın tek bir sorumluluğu olması için değişmesi için tek bir nedenin olması gerekir. Miras kodda bu, genellikle veritabanı erişimini, iş mantığını ve kullanıcı arayüzü biçimlendirmesini aynı anda ele alan bir sınıf olarak kendini gösterir.

Mevcut kod tabanınızda şu işaretlere bakın:

• Diğer bileşenlere aşırı bağımlılığı olan sınıflar.
• Birden fazla ilgisiz görevi gerçekleştiren yöntemler (ör. veriyi doğrulama ve e-posta gönderme).
• Dolambaçlı mantığı gösteren yüksek siklomatik karmaşıklık.
• İşbirlikçi geliştirme sırasında belirli dosyalarda sık sık birleşme çakışmaları.

Adım 1: Alan Mantığını Ayırma

Yeniden yapılandırmaya başlamanın en güvenli yolu, saf iş mantığını altyapı endişelerinden ayırmaktır. Toplam hesaplamadan veritabanını güncellemeye kadar her şeyi ele alan miras bir `OrderProcessor` sınıfını düşünün.

// Miras İhlali: Tanrı Nesnesi
public class OrderProcessor {
    public void processOrder(Order order) {
        // 1. İş Mantığı
        double tax = order.getTotal() * 0.1;
        order.setTotal(order.getTotal() + tax);

        // 2. Altyapı Endişesi
        databaseConnection.update("orders", order);

        // 3. Yan Etki
        emailService.sendConfirmation(order.getCustomerEmail());
    }
}

Bu sınıf üç nedenle değişir: vergi kuralları değişir, veritabanı şemaları değişir veya e-posta sağlayıcıları değişir. SRP'yi uygulamak için, hesaplama mantığını ayrı bir servise ayırırız.

Adım 2: Fiyatlandırma İçin Strateji Deseni Uygulama

Vergi hesaplamasını ayırarak bir `TaxCalculator` arayüzü oluştururuz. Bu, mantığı izole eder ve ana sipariş akışına dokunmadan uygulamaları değiştirmemizi sağlar.

// Yeni SRP'ye Uyumlu Yapı
public interface TaxCalculator {
    double calculate(Order order);
}

public class StandardTaxCalculator implements TaxCalculator {
    public double calculate(Order order) {
        return order.getTotal() * 0.1;
    }
}

// Yeniden Yapılandırılmış İşleyici
public class OrderProcessor {
    private final TaxCalculator taxCalculator;
    private final OrderRepository repository;
    private final NotificationService notifier;

    public OrderProcessor(TaxCalculator taxCalculator, OrderRepository repo, NotificationService notifier) {
        this.taxCalculator = taxCalculator;
        this.repository = repo;
        this.notifier = notifier;
    }

    public void processOrder(Order order) {
        order.setTotal(order.getTotal() + taxCalculator.calculate(order));
        repository.save(order);
        notifier.sendConfirmation(order);
    }
}

Adım 3: Altyapı Endişelerini Ayırma

Sonraki adımda, kalıcılık ve bildirim mantığının arayüzlere devredildiğinden emin oluruz. Bu, çekirdek iş sürecini belirli teknoloji seçimlerinden ayırır. `OrderProcessor` artık yalnızca soyutlamalar hakkında bilgi sahibidir; bu da sınıfı yalnızca iş akışını orkestrasyonla sınırlı tutarak SRP'yi destekleyen Bağımlılık Tersine Çevirme İlkesi'ne uyar.

Bu yeni uygulamayı test ederken, `TaxCalculator` ve `NotificationService`'i kolayca sahteleyebilirsiniz (mock). Daha önce, miras `OrderProcessor`'ün birim testi için bir veritabanı ve e-posta sunucusu kurulumu gerekiyordu, bu da testleri yavaş ve kararsız hale getiriyordu.

Geçiş Sürecini Yönetme

Büyük bir monoliti yeniden yapılandırmak risklidir. Bu riski azaltmak için "Strangler Fig" desenini kullanın. Yeni, SRP'ye uyumlu bileşenleri bir özellik bayrağının (feature flag) arkasına yerleştirin. Eski kod hâlâ varken trafiği kademeli olarak yeni uygulamaya yönlendirin. Yeni modüllerin kararlılığından emin olduğunuzda, miras kodu kaldırın.

Bu süreçte otomatik testler pazarlık konusu değildir. Herhangi bir miras koda dokunmadan önce, mevcut davranışı kapsayan entegrasyon testleri yazın. Bu testler, yeniden yapılandırmanızın yapıyı değiştirdiğinden ancak işlevselliği değiştirmediğinden emin olmanızı sağlayan güvenlik ağınız olarak hizmet eder.

Sonuç

Tek Sorumluluk İlkesi'ni miras koda uygulamak, her şeyi sıfırdan yeniden yazmakla ilgili değildir; kademeli iyileştirmeyle ilgilidir. İş mantığını izole ederek, altyapı endişelerini ayırarak ve bağımlılıkları yönetmek için tasarım desenlerini kullanarak, kırılgan monolitleri bakımı yapılabilir servislere dönüştürebilirsiniz. Küçük başlayın, kapsamlı test edin ve sınıf başına tek bir değişim nedeni disiplinine sadık kalın. Sonuç, yıllar boyunca daha kolay anlaşılır, test edilebilir ve genişletilebilir kod olacaktır.