Tekrarlayan Koddan Temiz Mimariye: Decorator Pattern ile Aktivite Kaydı %70 Daha Basit

Modern yazılım geliştirme süreçlerinde, uygulamanın kritik noktalarındaki kullanıcı veya sistem aktivitelerini kaydetmek vazgeçilmez bir gerekliliktir. Ancak bu işlem, sıklıkla tekrarlayan kodlara, bakımı zorlaşan modüllere ve mimari karmaşıklığa yol açabilir. Peki, bu kaostan kurtulup aktivite kaydını zarif ve sürdürülebilir bir şekilde nasıl yönetebiliriz? Cevap: Decorator Pattern.

Uygulamalar büyüdükçe ve işlevsellikleri arttıkça, hemen her işlem için bir tür kayıt tutma ihtiyacı doğar. Bir kullanıcının sepete ürün eklemesi, bir ödemenin onaylanması, bir yöneticinin ayarları güncellemesi gibi pek çok senaryo, ilgili aktivitenin ne zaman, kim tarafından ve hangi parametrelerle gerçekleştirildiğini izlemeyi gerektirir. Başlangıçta bu gereklilik basit görünse de, genellikle kontrolsüz bir kod kirliliğine yol açar. Geliştiriciler, “hızlı ve pratik” düşüncesiyle, iş mantığı kodlarının içine doğrudan kayıt (logging) çağrılarını eklemeye başlarlar. Örneğin, bir ürün ekleme servisi şöyle görünebilir:

class ProductService {
    public void AddProduct(Product product) {
        // Ürün ekleme iş mantığı
        productRepository.Add(product);
        logger.LogInfo($"Ürün '{product.Name}' eklendi.");
        notificationService.SendAdminNotification($"Yeni ürün eklendi: {product.Name}");
    }

    public void UpdateProduct(Product product) {
        // Ürün güncelleme iş mantığı
        productRepository.Update(product);
        logger.LogInfo($"Ürün '{product.Name}' güncellendi.");
        // Diğer işlemler...
    }
}

Bu yaklaşımın temel sorunları kısa sürede kendini göstermeye başlar. Öncelikle, kod tekrarı (DRY prensibinin ihlali) kaçınılmaz hale gelir. Her yeni metodun veya işlevselliğin eklenmesiyle birlikte, benzer kayıt satırları farklı yerlerde tekrar tekrar yazılmak zorunda kalır. Örneğin, sadece ürün ekleme değil, sipariş oluşturma, kullanıcı kaydı gibi farklı modüllerin de kendi kayıt mantıkları olacaktır. Bu durum, kod tabanının boyutunu gereksiz yere artırır ve okunabilirliği azaltır.

İkinci olarak, bakım zorluğu ortaya çıkar. Kayıt mekanizmasında bir değişiklik yapılması gerektiğinde (örneğin, kayıt formatının değiştirilmesi, farklı bir kayıt kütüphanesine geçilmesi veya kayıt seviyelerinin ayarlanması), bu değişikliklerin uygulamanın her yerine dağılmış yüzlerce satıra uygulanması gerekir. Bu da büyük bir zaman kaybına ve hata yapma riskine yol açar. Ayrıca, iş mantığı kodunun içine gömülü olan kayıt çağrıları, gerçek iş mantığının okunurluğunu bozar ve kodun anlaşılmasını zorlaştırır.

Üçüncü ve belki de en kritik sorun, test edilebilirliğin azalmasıdır. Kayıt mantığı, iş mantığı ile sıkı bir şekilde birleştiğinde, bir birim testi yazarken sadece iş mantığını test etmek zorlaşır. Kayıt çağrılarını mock'lamak veya gerçek bir kayıt mekanizmasıyla uğraşmak, testlerin karmaşıklığını artırır ve test sürecini yavaşlatır. Bu durum, genellikle geliştiricilerin test yazmaktan kaçınmasına veya yüzeysel testler yapmasına neden olur, bu da yazılım kalitesini olumsuz etkiler.

Son olarak, mimari esnekliğin kaybolması dikkat çeker. Kayıt işleminin birincil işlevden ayrılması, aslında çapraz kesen bir endişe (cross-cutting concern) olarak ele alınmalıdır. Yani, uygulamanın birçok farklı yerinde ihtiyaç duyulan ancak birincil iş mantığına doğrudan ait olmayan bir işlevdir. Bu tür endişeleri iş mantığına karıştırmak, modüllerin bağımlılıklarını artırır ve uygulamanın genişletilebilirliğini, yeniden kullanılabilirliğini ve genel olarak temiz mimari prensiplerine uygunluğunu zayıflatır. Bu yüzden, aktivite kayıtlarını ele alırken daha soyut ve esnek bir yaklaşıma ihtiyacımız var.

Decorator Pattern Nedir ve Temel Felsefesi Ne Anlama Gelir?

Decorator Pattern, yazılım tasarım desenleri dünyasında "yapısal desenler" kategorisinde yer alır ve bir nesneye, mevcut yapısını değiştirmeden yeni sorumluluklar dinamik olarak eklemenizi sağlar. Kısacası, bir nesnenin etrafına "süslemeler" ekleyerek onun davranışını genişletme veya değiştirme prensibine dayanır. Bu desen, GoF (Gang of Four) tarafından tanımlanmış 23 klasik tasarım deseninden biridir ve özellikle esnekliğin ve genişletilebilirliğin kritik olduğu senaryolarda hayat kurtarıcı olabilir.

Peki, bu ne anlama geliyor? Geleneksel olarak, bir nesneye yeni özellikler eklemek istediğimizde, ya o nesnenin sınıfını miras alırız (kalıtım) ya da yeni bir sınıf oluşturup orijinal nesneyi içinde tutarız (kompozisyon). Decorator Pattern, bu iki yaklaşımın avantajlarını birleştirir: kalıtımın esnekliğini, kompozisyonun gücüyle harmanlar. Temel felsefesi, bir nesnenin davranışını derleme zamanında değil, çalışma zamanında değiştirebilme yeteneğidir.

Bu desenin temel bileşenlerini daha iyi anlayabilmek için, bir kahve siparişi örneğini düşünebiliriz. Bir sade kahve (ConcreteComponent) sipariş ettiğinizde, üzerine süt (ConcreteDecorator), krema (ConcreteDecorator) veya şurup (ConcreteDecorator) ekleyebilirsiniz. Her ekleme, kahvenin orijinal tadını (işlevini) değiştirmeden yeni bir özellik (süsleme) ekler ve toplam fiyatını (davranışını) artırır. İşte bu örnek, Decorator Pattern'ın nasıl çalıştığını mükemmel bir şekilde özetler.

Decorator Pattern'ın anahtar bileşenleri şunlardır:

1. Component (Bileşen): Hem dekore edilecek nesneler hem de dekoratörler için ortak arayüzü veya soyut sınıfı tanımlar. Bu, istemcinin (client) dekore edilmiş veya dekore edilmemiş nesneleri aynı şekilde ele almasını sağlar. Örneğin, IKahve arayüzü.
2. ConcreteComponent (Somut Bileşen): Component arayüzünü uygulayan ve dekoratörler tarafından dekore edilecek olan orijinal nesnedir. Örneğin, SadeKahve sınıfı.
3. Decorator (Dekoratör): Component arayüzünü uygulayan ve bir Component referansını tutan soyut bir sınıftır. Bu sınıfın ana amacı, dekore edilecek nesneye referans tutmak ve onun metodunu çağırmaktır. Bu, dekore edilen nesneye "süslemeler" eklemek için bir iskelet görevi görür. Örneğin, KahveDekoratoru soyut sınıfı.
4. ConcreteDecorator (Somut Dekoratör): Decorator sınıfını miras alan ve belirli bir ek sorumluluk ekleyen somut sınıflardır. Her somut dekoratör, dekore edilen nesnenin işlevselliğini genişletir. Örneğin, SutluKahve, KremaliKahve sınıfları.

Bu desenin sağladığı en büyük avantajlardan biri, işlevselliği kalıtım hiyerarşisinin katılığına bağlı kalmadan genişletebilmesidir. Kalıtım ile, bir sınıfın davranışını değiştirmek veya genişletmek istediğinizde yeni bir alt sınıf oluşturmanız gerekir. Bu, çok fazla alt sınıfın oluşmasına ve hiyerarşinin karmaşıklaşmasına yol açabilir. Decorator Pattern, bu sorunu kompozisyon ve arayüzler aracılığıyla aşar, böylece daha modüler ve dinamik bir yapı sunar. Bu temel anlayışla, aktivite kayıtlarını nasıl basitleştirebileceğimize geçebiliriz.

Decorator Pattern ile Aktivite Kaydı Nasıl Dönüşür? Adım Adım Bir Uygulama

Aktivite kayıtlarını, iş mantığından ayırarak daha modüler ve esnek bir yapıya kavuşturmak için Decorator Pattern'ı adım adım nasıl uygulayacağımızı inceleyelim. Senaryomuz, bir e-ticaret uygulamasında "sipariş işleme" hizmetlerini kaydetmek olsun.

1. Temel Servis Arayüzünü Tanımlama (Component)

Öncelikle, dekore edilecek olan temel işlevselliği temsil eden bir arayüz tanımlamalıyız. Bu, istemcilerin hem temel hizmeti hem de dekore edilmiş hizmetleri aynı şekilde kullanabilmesini sağlayacaktır.

// C# örneği
public interface ISiparisServisi
{
    void SiparisOlustur(int userId, List urunIdleri);
    void SiparisGuncelle(int siparisId, string durum);
    void SiparisIptalEt(int siparisId);
}

Bu arayüz, siparişlerle ilgili temel operasyonları tanımlar. Artık hangi somut sınıfın bu arayüzü uyguladığını veya bu metodların ekstra bir özelliği olup olmadığını dert etmeden, ISiparisServisi tipinde bir nesne ile çalışabiliriz.

2. Somut Servis Uygulaması (ConcreteComponent)

Şimdi, temel iş mantığını içeren gerçek sipariş hizmetini uygulayalım. Bu sınıf, herhangi bir kayıt veya ek işlevsellik barındırmamalı, sadece siparişlerle ilgili çekirdek işleri yapmalıdır.

public class GercekSiparisServisi : ISiparisServisi
{
    public void SiparisOlustur(int userId, List urunIdleri)
    {
        Console.WriteLine($"Kullanıcı {userId} için sipariş oluşturuluyor, ürünler: {string.Join(", ", urunIdleri)}.");
        // Veritabanı işlemleri, stok kontrolü vb.
        Console.WriteLine("Sipariş başarıyla oluşturuldu.");
    }

    public void SiparisGuncelle(int siparisId, string durum)
    {
        Console.WriteLine($"Sipariş {siparisId} durumu '{durum}' olarak güncelleniyor.");
        // Veritabanı güncelleme işlemleri
        Console.WriteLine("Sipariş durumu güncellendi.");
    }

    public void SiparisIptalEt(int siparisId)
    {
        Console.WriteLine($"Sipariş {siparisId} iptal ediliyor.");
        // Veritabanı işlemleri, iade süreci başlatma vb.
        Console.WriteLine("Sipariş iptal edildi.");
    }
}

Gördüğünüz gibi, bu sınıf tamamen "saf" iş mantığı içerir. Hiçbir kayıt çağrısı veya bildirim mantığı bulunmuyor. Bu, test edilebilirliğini ve okunabilirliğini artırıyor.

3. Soyut Dekoratör Sınıfını Tanımlama (Decorator)

Tüm dekoratörler için temel bir yapı sağlayacak olan soyut dekoratör sınıfını oluşturmalıyız. Bu sınıf, ISiparisServisi arayüzünü uygulamalı ve dekore edilecek ISiparisServisi nesnesine bir referans tutmalıdır.

public abstract class SiparisServisiDekoratoru : ISiparisServisi
{
    protected ISiparisServisi _siparisServisi;

    public SiparisServisiDekoratoru(ISiparisServisi siparisServisi)
    {
        _siparisServisi = siparisServisi;
    }

    // Her metodu varsayılan olarak temel servise yönlendiriyoruz.
    // Alt sınıflar bu metodları override ederek ek işlevsellik ekleyecekler.
    public virtual void SiparisOlustur(int userId, List urunIdleri)
    {
        _siparisServisi.SiparisOlustur(userId, urunIdleri);
    }

    public virtual void SiparisGuncelle(int siparisId, string durum)
    {
        _siparisServisi.SiparisGuncelle(siparisId, durum);
    }

    public virtual void SiparisIptalEt(int siparisId)
    {
        _siparisServisi.SiparisIptalEt(siparisId);
    }
}

Burada, _siparisServisi alanını kullanarak temel servise erişim sağlıyoruz. Metodlar virtual olarak işaretlenmiştir, böylece alt sınıflar (somut dekoratörler) bunları geçersiz kılarak kendi özel davranışlarını ekleyebilirler.

4. Kayıt Dekoratörünü Uygulama (ConcreteDecorator)

Şimdi, asıl amacımız olan aktivite kaydını sağlayan somut dekoratörü oluşturalım. Bu dekoratör, SiparisServisiDekoratoru sınıfını miras alacak ve metodları geçersiz kılarak ek kayıt mantığını dahil edecektir.

public class LoglamaSiparisServisiDekoratoru : SiparisServisiDekoratoru
{
    public LoglamaSiparisServisiDekoratoru(ISiparisServisi siparisServisi)
        : base(siparisServisi)
    {
    }

    public override void SiparisOlustur(int userId, List urunIdleri)
    {
        Console.WriteLine($"[LOG] Sipariş oluşturma talebi alındı. Kullanıcı ID: {userId}");
        _siparisServisi.SiparisOlustur(userId, urunIdleri); // Temel işlemi çağır
        Console.WriteLine($"[LOG] Sipariş {userId} için başarıyla oluşturuldu.");
    }

    public override void SiparisGuncelle(int siparisId, string durum)
    {
        Console.WriteLine($"[LOG] Sipariş {siparisId} için durum güncelleme talebi alındı. Yeni Durum: {durum}");
        _siparisServisi.SiparisGuncelle(siparisId, durum); // Temel işlemi çağır
        Console.WriteLine($"[LOG] Sipariş {siparisId} durumu '{durum}' olarak güncellendi.");
    }

    public override void SiparisIptalEt(int siparisId)
    {
        Console.WriteLine($"[LOG] Sipariş {siparisId} için iptal talebi alındı.");
        _siparisServisi.SiparisIptalEt(siparisId); // Temel işlemi çağır
        Console.WriteLine($"[LOG] Sipariş {siparisId} başarıyla iptal edildi.");
    }
}

Bu dekoratör, her bir metodun öncesine ve sonrasına kayıt mantığını eklerken, temel işi _siparisServisi.Siparis...() çağrıları ile gerçekleştirmeye devam ediyor. Bu sayede kayıt mantığı, iş mantığından tamamen ayrılmış oluyor.

5. Kullanım ve Kompozisyon

Artık istemci kodu, hangi hizmeti kullanmak istediğini dinamik olarak seçebilir. Kayıt özellikli bir servis mi istiyor? Sadece LoglamaSiparisServisiDekoratoru ile sarmalaması yeterli.

// İstemci tarafında kullanım
public class Client
{
    public static void Main(string[] args)
    {
        // Temel sipariş servisi
        ISiparisServisi gercekServis = new GercekSiparisServisi();

        // Kayıt eklenmiş sipariş servisi
        ISiparisServisi logluServis = new LoglamaSiparisServisiDekoratoru(gercekServis);

        Console.WriteLine("--- Logsuz Servis Kullanımı ---");
        gercekServis.SiparisOlustur(101, new List { 1, 2 });
        gercekServis.SiparisGuncelle(500, "Hazırlanıyor");
        Console.WriteLine("-----------------------------");

        Console.WriteLine("--- Loglu Servis Kullanımı ---");
        logluServis.SiparisOlustur(102, new List { 3, 4 });
        logluServis.SiparisIptalEt(501);
        Console.WriteLine("----------------------------");
    }
}

Bu çıktı, her iki durumda da temel iş mantığının çalıştığını, ancak yalnızca logluServis kullanıldığında kayıt mesajlarının görüntülendiğini gösterecektir. Bu yapı sayesinde, uygulamanızın herhangi bir yerine kayıt özelliği eklemek istediğinizde, mevcut kodunuzu (GercekSiparisServisi) değiştirmek zorunda kalmazsınız. Sadece yeni bir dekoratör yaratır ve mevcut servisi onunla sarmalarsınız. Bu, Açık/Kapalı prensibine mükemmel bir uyum sağlar ve aktivite kayıtları gibi çapraz kesen endişelerin yönetimini %70 veya daha fazla oranda basitleştirebilir.

Gerçek Dünya Senaryosu: Bir E-Ticaret Platformunda Sepet İşlemlerini Kaydetme

Bir e-ticaret platformunun "sepet" modülü, kullanıcı deneyiminin kalbi niteliğindedir. Kullanıcının ürünleri sepete eklemesi, çıkarması, miktarını güncellemesi veya sepeti boşaltması gibi her işlem kritik öneme sahiptir. Bu işlemlerin doğru bir şekilde kaydedilmesi, hem hata ayıklama (debugging) için hem de iş analizi, kullanıcı davranışı takibi ve güvenlik denetimleri için elzemdir. Ancak bu kadar çok işlemde kayıt mantığını her yere serpiştirmek, az önce bahsettiğimiz "tekrar eden kod kabusu"nu yaratır.

Dekoratör Öncesi Durum: Tekrarlayan ve Bakımı Zor Kod

Dekoratör desenini kullanmadan önce, bir e-ticaret uygulamasında sepet işlemleri şöyle görünebilirdi:

// Tekrarlayan kod öncesi
public interface ISepetServisi
{
    void UrunEkle(string userId, string productId, int quantity);
    void UrunCikar(string userId, string productId);
    void MiktarGuncelle(string userId, string productId, int newQuantity);
    void SepetiBosalt(string userId);
}

public class SomutSepetServisi : ISepetServisi
{
    private readonly ILogger _logger;
    private readonly ISepetRepository _sepetRepository;

    public SomutSepetServisi(ILogger logger, ISepetRepository sepetRepository)
    {
        _logger = logger;
        _sepetRepository = sepetRepository;
    }

    public void UrunEkle(string userId, string productId, int quantity)
    {
        _logger.LogInfo($"[İşlem Başladı] Kullanıcı {userId}, ürünü {productId} sepete ekliyor. Miktar: {quantity}.");
        _sepetRepository.AddProductToCart(userId, productId, quantity);
        _logger.LogInfo($"[İşlem Tamamlandı] Kullanıcı {userId}, ürünü {productId} sepete ekledi.");
    }

    public void UrunCikar(string userId, string productId)
    {
        _logger.LogInfo($"[İşlem Başladı] Kullanıcı {userId}, ürünü {productId} sepetten çıkarıyor.");
        _sepetRepository.RemoveProductFromCart(userId, productId);
        _logger.LogInfo($"[İşlem Tamamlandı] Kullanıcı {userId}, ürünü {productId} sepetten çıkardı.");
    }

    public void MiktarGuncelle(string userId, string productId, int newQuantity)
    {
        _logger.LogInfo($"[İşlem Başladı] Kullanıcı {userId}, ürünü {productId} miktarını {newQuantity} olarak güncelliyor.");
        _sepetRepository.UpdateProductQuantity(userId, productId, newQuantity);
        _logger.LogInfo($"[İşlem Tamamlandı] Kullanıcı {userId}, ürünü {productId} miktarını güncelledi.");
    }

    public void SepetiBosalt(string userId)
    {
        _logger.LogInfo($"[İşlem Başladı] Kullanıcı {userId} sepetini boşaltıyor.");
        _sepetRepository.ClearCart(userId);
        _logger.LogInfo($"[İşlem Tamamlandı] Kullanıcı {userId} sepetini boşalttı.");
    }
}

Bu örnekte, her metodun içinde kayıt çağrılarını (_logger.LogInfo(...)) görebilirsiniz. Bu, modülün birincil sorumluluğu olan "sepet işlemlerini yönetme" ile ikincil bir sorumluluk olan "kayıt tutma"yı bir araya getiriyor. Sonuç olarak:

• Her yeni sepet işlemi için benzer kayıt kodları tekrar tekrar yazılmak zorunda kalıyor.
• Kayıt mekanizmasında bir değişiklik yapılması gerektiğinde (örneğin, farklı bir loglama kütüphanesine geçiş), SomutSepetServisi sınıfının her metodunun güncellenmesi gerekiyor.
• SomutSepetServisi sınıfının testleri, hem sepet iş mantığını hem de kayıt mantığını içermek zorunda kalıyor, bu da testlerin karmaşıklığını artırıyor.
• Kod, sepet işlevselliği ile kayıt işlevselliği arasında sıkı bir bağımlılığa sahip oluyor.

Dekoratör Sonrası Durum: Temiz, Genişletilebilir ve Bakımı Kolay Kod

Decorator Pattern kullanarak bu sorunları nasıl çözdüğümüze bakalım. İlk olarak, ISepetServisi arayüzümüz aynı kalır.

// Decorator sonrası - ISepetServisi aynı kalır
public interface ISepetServisi
{
    void UrunEkle(string userId, string productId, int quantity);
    void UrunCikar(string userId, string productId);
    void MiktarGuncelle(string userId, string productId, int newQuantity);
    void SepetiBosalt(string userId);
}

Şimdi, SomutSepetServisi sınıfını kayıt mantığından arındırıyoruz. Sadece kendi temel işlevselliğine odaklanıyor:

// Decorator sonrası - Temiz SomutSepetServisi
public class SomutSepetServisi : ISepetServisi
{
    private readonly ISepetRepository _sepetRepository;

    public SomutSepetServisi(ISepetRepository sepetRepository)
    {
        _sepetRepository = sepetRepository;
    }

    public void UrunEkle(string userId, string productId, int quantity)
    {
        Console.WriteLine($"Sepet: Kullanıcı {userId}, ürünü {productId} ({quantity} adet) sepete ekliyor.");
        _sepetRepository.AddProductToCart(userId, productId, quantity);
    }

    public void UrunCikar(string userId, string productId)
    {
        Console.WriteLine($"Sepet: Kullanıcı {userId}, ürünü {productId} sepetten çıkarıyor.");
        _sepetRepository.RemoveProductFromCart(userId, productId);
    }

    public void MiktarGuncelle(string userId, string productId, int newQuantity)
    {
        Console.WriteLine($"Sepet: Kullanıcı {userId}, ürünü {productId} miktarını {newQuantity} olarak güncelliyor.");
        _sepetRepository.UpdateProductQuantity(userId, productId, newQuantity);
    }

    public void SepetiBosalt(string userId)
    {
        Console.WriteLine($"Sepet: Kullanıcı {userId} sepetini boşaltıyor.");
        _sepetRepository.ClearCart(userId);
    }
}

Gördüğünüz gibi, bu sınıf artık sadece sepet işlemlerine odaklanmış durumda. Kayıt çağrıları tamamen dışarı taşındı. Şimdi bir SepetServisiDekoratoru soyut sınıfı ve bir LoglamaSepetServisiDekoratoru somut sınıfı oluşturalım:

// Soyut Sepet Servisi Dekoratoru
public abstract class SepetServisiDekoratoru : ISepetServisi
{
    protected ISepetServisi _sepetServisi;

    public SepetServisiDekoratoru(ISepetServisi sepetServisi)
    {
        _sepetServisi = sepetServisi;
    }

    public virtual void UrunEkle(string userId, string productId, int quantity) => _sepetServisi.UrunEkle(userId, productId, quantity);
    public virtual void UrunCikar(string userId, string productId) => _sepetServisi.UrunCikar(userId, productId);
    public virtual void MiktarGuncelle(string userId, string productId, int newQuantity) => _sepetServisi.MiktarGuncelle(userId, productId, newQuantity);
    public virtual void SepetiBosalt(string userId) => _sepetServisi.SepetiBosalt(userId);
}

// Loglama Sepet Servisi Dekoratoru
public class LoglamaSepetServisiDekoratoru : SepetServisiDekoratoru
{
    private readonly ILogger _logger; // Gerçek bir logger bağımlılığı

    public LoglamaSepetServisiDekoratoru(ISepetServisi sepetServisi, ILogger logger)
        : base(sepetServisi)
    {
        _logger = logger;
    }

    public override void UrunEkle(string userId, string productId, int quantity)
    {
        _logger.LogInfo($"[LOG] Kullanıcı {userId} ürünü {productId} sepete ekledi. Miktar: {quantity}.");
        _sepetServisi.UrunEkle(userId, productId, quantity); // Temel işlemi çağır
        _logger.LogInfo($"[LOG] Kullanıcı {userId} için sepet güncelleme başarılı.");
    }

    public override void UrunCikar(string userId, string productId)
    {
        _logger.LogInfo($"[LOG] Kullanıcı {userId} ürünü {productId} sepetten çıkardı.");
        _sepetServisi.UrunCikar(userId, productId);
        _logger.LogInfo($"[LOG] Kullanıcı {userId} için sepet güncelleme başarılı.");
    }

    public override void MiktarGuncelle(string userId, string productId, int newQuantity)
    {
        _logger.LogInfo($"[LOG] Kullanıcı {userId} ürünü {productId} miktarını {newQuantity} olarak güncelledi.");
        _sepetServisi.MiktarGuncelle(userId, productId, newQuantity);
        _logger.LogInfo($"[LOG] Kullanıcı {userId} için sepet güncelleme başarılı.");
    }

    public override void SepetiBosalt(string userId)
    {
        _logger.LogInfo($"[LOG] Kullanıcı {userId} sepetini boşalttı.");
        _sepetServisi.SepetiBosalt(userId);
        _logger.LogInfo($"[LOG] Kullanıcı {userId} için sepet boşaltma başarılı.");
    }
}

Ve son olarak, bağımlılık enjeksiyonu (Dependency Injection - DI) veya manuel olarak bu dekoratörü nasıl kullanacağımız:

// Uygulama başlangıcı veya bağımlılık yapılandırması
public class ECommerceApp
{
    public static void Main(string[] args)
    {
        // Mock logger ve repository (gerçek uygulamada DI ile inject edilir)
        ILogger logger = new ConsoleLogger(); // Basit bir konsol logger
        ISepetRepository sepetRepository = new InMemorySepetRepository(); // Basit bir bellek içi repo

        // Temel sepet servisi
        ISepetServisi gercekSepetServisi = new SomutSepetServisi(sepetRepository);

        // Kayıt özellikli sepet servisi
        ISepetServisi loglananSepetServisi = new LoglamaSepetServisiDekoratoru(gercekSepetServisi, logger);

        Console.WriteLine("--- Loglu Sepet İşlemleri ---");
        loglananSepetServisi.UrunEkle("user123", "P001", 2);
        loglananSepetServisi.MiktarGuncelle("user123", "P001", 3);
        loglananSepetServisi.UrunCikar("user123", "P002");
        loglananSepetServisi.SepetiBosalt("user123");
        Console.WriteLine("-----------------------------");

        // İhtiyaç olursa logsuz servis de kullanılabilir
        Console.WriteLine("\n--- Logsuz Sepet İşlemleri (Test Amaçlı) ---");
        gercekSepetServisi.UrunEkle("user456", "P005", 1);
        Console.WriteLine("------------------------------------------");
    }
}

// Basit ILogger ve ISepetRepository implementasyonları
public interface ILogger { void LogInfo(string message); }
public class ConsoleLogger : ILogger { public void LogInfo(string message) { Console.WriteLine(message); } }
public interface ISepetRepository
{
    void AddProductToCart(string userId, string productId, int quantity);
    void RemoveProductFromCart(string userId, string productId);
    void UpdateProductQuantity(string userId, string productId, int newQuantity);
    void ClearCart(string userId);
}
public class InMemorySepetRepository : ISepetRepository
{
    public void AddProductToCart(string userId, string productId, int quantity) { /* ... */ }
    public void RemoveProductFromCart(string userId, string productId) { /* ... */ }
    public void UpdateProductQuantity(string userId, string productId, int newQuantity) { /* ... */ }
    public void ClearCart(string userId) { /* ... */ }
}

Bu yeni yapı ile birlikte, aktivite kayıtları tamamen LoglamaSepetServisiDekoratoru içine taşınmıştır. SomutSepetServisi artık sadece sepetin iş mantığına odaklanır. Bu, kod tekrarını önemli ölçüde azaltır, bakımı kolaylaştırır ve her bir modülün tek bir sorumluluğu olmasına yardımcı olur (SRP - Single Responsibility Principle). Ayrıca, bir gün kayıt tutma şeklinizi değiştirmek istediğinizde, sadece dekoratör sınıfını güncellemeniz veya yeni bir dekoratör eklemeniz yeterli olacaktır. Tahmini olarak, bu yaklaşım aktivite kaydıyla ilgili kod satırı miktarını ve bakım karmaşıklığını %70 veya daha fazla azaltabilir.

Performans ve Genişletilebilirlik: Decorator Pattern'ın Gizli Güçleri Nelerdir?

Decorator Pattern, sadece kod tekrarını azaltmakla kalmaz, aynı zamanda bir uygulamanın performansını ve genişletilebilirliğini de önemli ölçüde artırabilir. Ancak, her tasarım deseni gibi, doğru bağlamda ve bilinçli bir şekilde kullanılması gerekir. Gelin, bu desenin "gizli güçlerine" ve olası performans etkilerine daha yakından bakalım.

Dekoratörleri Zincirleme ve Dinamik Davranış

Decorator Pattern'ın en güçlü yanlarından biri, birden fazla dekoratörü birbiri üzerine zincirleyebilme yeteneğidir. Bu, aynı temel nesneye farklı sorumlulukları dinamik olarak ekleyebileceğiniz anlamına gelir. Örneğin, bir sepet servisi için hem kayıt tutma, hem yetkilendirme kontrolü, hem de önbellekleme (caching) özelliklerini eklemek isteyebilirsiniz. Bunu her bir özelliği ayrı bir dekoratör olarak uygulayarak ve bu dekoratörleri birbiri üzerine sarmalayarak kolayca başarabilirsiniz:

// Farklı dekoratörler
ISepetServisi sepetServisi = new SomutSepetServisi(sepetRepository);
ISepetServisi yetkiKontrolluServis = new YetkilendirmeSepetServisiDekoratoru(sepetServisi, yetkiKontrolcusu);
ISepetServisi loglananYetkiliServis = new LoglamaSepetServisiDekoratoru(yetkiKontrolluServis, logger);
ISepetServisi onbellekliLoglananYetkiliServis = new OnbelleklemeSepetServisiDekoratoru(loglananYetkiliServis, cacheServisi);

// Artık 'onbellekliLoglananYetkiliServis' hem önbellekleme, hem loglama, hem yetkilendirme özelliklerine sahip!
onbellekliLoglananYetkiliServis.UrunEkle("user789", "P010", 1);

Bu zincirleme yapısı, kod tabanınızda her bir özellik kombinasyonu için ayrı bir sınıf oluşturmaktan sizi kurtarır. Her özellik, kendi dekoratörü içinde kapsüllenir ve istediğiniz zaman eklenip çıkarılabilir. Bu, uygulamanıza inanılmaz bir esneklik ve dinamik davranış kazandırır. Yeni bir özellik (örneğin, bir bildirim servisi) eklemek istediğinizde, sadece yeni bir dekoratör yazar ve onu mevcut zincire eklersiniz; var olan hiçbir kodu değiştirmenize gerek kalmaz.

Performans Üzerindeki Etkileri: Potansiyel Ek Yükler

Her soyutlama katmanı gibi, Decorator Pattern da performansa belirli bir ek yük getirebilir. Her dekoratör, temel metod çağrısını sarmaladığı ve kendi ek mantığını uyguladığı için, bir metod çağrısının gerçekleşmesi için birden fazla nesne üzerinden geçmesi gerekebilir. Bu ek yükler şunları içerebilir:

• Nesne Oluşturma: Her bir dekoratör, bellekte ek bir nesne oluşturulması anlamına gelir. Çok sayıda dekoratörün zincirlendiği ve sıkça oluşturulduğu senaryolarda bu, bellek tüketimini artırabilir.
• Metod Çağrısı Yükü: Temel metod çağrısına ulaşmak için birden fazla sanal metod çağrısı (virtual method call) yapılması gerekebilir. Modern JIT derleyicileri bu tür yükleri optimize etse de, aşırı derin bir dekoratör zinciri teorik olarak küçük bir performans düşüşüne neden olabilir.
• Ek İşlem Yükü: Her dekoratör, ek bir sorumluluk (örneğin kayıt tutma, yetkilendirme kontrolü, önbellek kontrolü) eklediği için, bu ek iş mantığının kendisi de zaman ve kaynak tüketir. Ancak bu, dekoratör deseninden bağımsız olarak, bu özelliklerin bir şekilde uygulanması gerektiği gerçeğidir.

Pratikte, çoğu modern uygulamada ve donanımda bu performans ek yükleri genellikle ihmal edilebilir düzeydedir ve elde edilen mimari faydalar (bakım kolaylığı, esneklik, test edilebilirlik) bu küçük maliyetten çok daha değerlidir. Performansın aşırı kritik olduğu yüksek frekanslı, düşük gecikmeli sistemlerde, her soyutlama katmanı dikkatle değerlendirilmeli ve gerekirse farklı optimizasyon yaklaşımları (örneğin AOP kütüphaneleri) düşünülmelidir. Ancak aktivite kaydı gibi çoğu çapraz kesen endişe için Decorator Pattern, harika bir dengeli çözüm sunar.

Bağımlılık Enjeksiyonu (DI) ile Entegrasyon

Decorator Pattern, modern uygulamalarda sıklıkla kullanılan Bağımlılık Enjeksiyonu (Dependency Injection - DI) konteynerleri ile kusursuz bir şekilde entegre olur. DI konteynerleri (örneğin .NET'teki Microsoft.Extensions.DependencyInjection, Spring'deki IoC konteyneri), dekoratör zincirlerini otomatik olarak oluşturmak ve yönetmek için kullanılabilir. Bu, istemci kodunun hangi dekoratörlerin uygulanacağı veya hangi sırayla sarmalanacağı hakkında bilgi sahibi olmasına gerek kalmadan temiz ve esnek bir mimari oluşturmanızı sağlar.

// C# .NET Core IServiceCollection ile yapılandırma örneği
public void ConfigureServices(IServiceCollection services)
{
    // Temel servisi kaydet
    services.AddScoped();

    // Dekorasyonları zincirle (kayıt -> yetkilendirme -> önbellekleme)
    services.Decorate();
    services.Decorate();
    services.Decorate();

    // Diğer bağımlılıklar
    services.AddSingleton();
    services.AddScoped();
    services.AddScoped();
    services.AddSingleton();
}

Bu yapılandırma ile, uygulamanın herhangi bir yerinde ISepetServisi talep edildiğinde, DI konteyneri otomatik olarak en dıştaki dekoratörden başlayarak (bu örnekte OnbelleklemeSepetServisiDekoratoru) tüm zinciri oluşturacak ve istemciye tamamen dekore edilmiş servisi sağlayacaktır. Bu, uygulamanın modülerliğini ve bakılabilirliğini büyük ölçüde artırır. Geliştiricilerin, iş mantığını değiştirmeden veya mevcut kodda karmaşık bağımlılık yapılandırmaları yapmadan yeni özellikler eklemesine olanak tanır. Kısacası, Decorator Pattern'ın genişletilebilirlik gücü, DI ile birleştiğinde zirveye ulaşır.

Decorator Pattern Ne Zaman Kullanılmalı, Ne Zaman Kaçınılmalı?

Decorator Pattern, aktivite kayıtları gibi çapraz kesen endişelerin yönetiminde harika bir araç olsa da, her probleme uygun değildir. Doğru bağlamda kullanıldığında parlarken, yanlış yerde kullanıldığında kodu gereksiz yere karmaşıklaştırabilir. Bu nedenle, ne zaman kullanılacağını ve ne zaman alternatiflere yönelmek gerektiğini iyi anlamak önemlidir.

Decorator Pattern Ne Zaman Parlar?

1. Sorumlulukları Dinamik Olarak Ekleme İhtiyacı: Bir nesneye çalışma zamanında yeni işlevsellik eklemek istediğinizde idealdir. Örneğin, belirli koşullara göre (örneğin, kullanıcının rolü, sistemin modu) farklı davranışlar sergilemesi gereken bir servisiniz varsa.
2. Çapraz Kesen Endişelerin Yönetimi: Kayıt (logging), yetkilendirme (authorization), önbellekleme (caching), performans ölçümü (monitoring), hata işleme (error handling) gibi birden fazla modülü etkileyen ancak birincil iş mantığına ait olmayan işlevler için mükemmeldir. Decorator, bu endişeleri iş mantığından ayırarak Single Responsibility Principle'ı (Tek Sorumluluk Prensibi) destekler.
3. Kalıtım Hiyerarşisi Patlamasını Önleme: Eğer kalıtım yoluyla işlevsellik eklemeye çalışırken çok sayıda alt sınıf oluşturmak zorunda kalıyorsanız (örneğin, SutluKremaliKahve, SutluSekerliKahve gibi), Decorator Pattern bu "sınıf hiyerarşisi patlamasını" önleyerek daha esnek bir alternatif sunar. Her özellik için ayrı bir sınıf oluşturmak yerine, bunları dekoratörler aracılığıyla zincirleyebilirsiniz.
4. Mevcut Kodun Değiştirilmeden Genişletilmesi (Open/Closed Principle): Bir sınıfın veya arayüzün davranışını, orijinal kodu değiştirmeden genişletmek istediğinizde çok etkilidir. Bu, uygulamanızın daha az hata barındırmasını ve gelecekteki değişikliklere daha açık olmasını sağlar.

Decorator Pattern Ne Zaman Kaçınılmalı veya Alternatifler Düşünülmeli?

1. Çok Fazla Küçük Nesne Yaratılması: Eğer dekoratör zinciriniz çok uzun ve her dekoratör çok basit bir iş yapıyorsa, bu durum gereksiz yere fazla nesne oluşturulmasına ve kodun okunurluğunun azalmasına neden olabilir. Bu tür durumlarda, daha kapsamlı bir dekoratör veya başka bir desen daha uygun olabilir.
2. Karmaşıklığın Gereksiz Artması: Basit bir sorunu çözmek için Decorator Pattern'ı kullanmak, gereksiz soyutlamalar ve arayüzler yaratarak kodu karmaşıklaştırabilir. Eğer bir nesnenin davranışını nadiren veya yalnızca birkaç sabit yolla genişletmeniz gerekiyorsa, basit kalıtım veya kompozisyon yeterli olabilir.
3. AOP (Aspect-Oriented Programming) Alternatifi: Kayıt, yetkilendirme gibi çapraz kesen endişeler için AOP kütüphaneleri (örneğin AspectJ, PostSharp) de güçlü bir alternatiftir. AOP, bu tür endişeleri "enjeksiyon" veya "vekil (proxy) oluşturma" yoluyla otomatik olarak ana iş mantığına ekleyerek kod tekrarını azaltır. Decorator Pattern'a benzer bir amaca hizmet etse de, farklı bir uygulama mekanizmasına sahiptir ve bazı durumlarda daha az manuel yapılandırma gerektirebilir.
4. Performansın Aşırı Kritik Olduğu Durumlar: Çok yüksek performans gerektiren, mikrosaniyelerle ölçülen gecikmelerin bile önemli olduğu sistemlerde, her soyutlama katmanı (ve dolayısıyla her sanal metod çağrısı) dikkatle değerlendirilmelidir. Bu tür durumlarda, daha düşük seviyeli, daha az soyutlama içeren optimizasyonlar veya AOP gibi derleme zamanı müdahaleleri daha uygun olabilir.
5. Nesnenin Kimliğinin Önemli Olduğu Durumlar: Decorator Pattern, bir nesnenin kimliğini değiştirmeden davranışını genişletir. Ancak, eğer dekorasyon işlemi nesnenin "kimliğini" (örneğin, == operatörü veya hash kodu) değiştirmemesi gereken ancak istemci kodunun bu kimliği kontrol ettiği durumlarda dikkatli olunmalıdır. Genellikle, dekore edilmiş nesne, temel nesnenin bir referansını tuttuğu için kimlik koruma sağlanır, ancak bu bir tasarım detayıdır.

Özetle, Decorator Pattern güçlü bir araçtır ancak her zaman en iyi çözüm değildir. Uygulamanızın ihtiyaçlarını, karmaşıklığını ve gelecekteki genişletilebilirlik beklentilerini dikkatlice değerlendirerek doğru kararı vermelisiniz. Aktivite kaydı gibi tekrarlayan ve çapraz kesen görevler için genellikle mükemmel bir seçimdir, çünkü iş mantığını temiz tutarken bu tür görevleri zarifçe ele almanızı sağlar.

Sonuç: Tekrarlayan Koddan Temiz Mimariye Geçişin Anahtarı

Modern yazılım geliştirme, sürekli değişen gereksinimler ve artan karmaşıklıkla karakterize edilir. Bu ortamda, kod tekrarı ve bakımı zor yapılar, geliştirme sürecini yavaşlatan ve hatalara davetiye çıkaran en büyük engellerden biridir. Aktivite kaydı gibi uygulamanın birçok farklı noktasında ortaya çıkan çapraz kesen endişeler, bu tekrarın ve karmaşıklığın en sık rastlanan kaynaklarından biridir.

Bu makalede incelediğimiz Decorator Pattern, tam da bu tür sorunlara zarif ve etkili bir çözüm sunar. İş mantığını kayıt tutma veya diğer ek sorumluluklardan ayırarak, uygulamalarımızın çekirdek işlevselliğini saf, okunabilir ve test edilebilir tutmamızı sağlar. Bu sayede, aktivite kaydı gibi tekrarlayan görevler, ana iş mantığının içine dağılmaktan kurtulur ve merkezi, değiştirilmesi kolay bir yapıya kavuşur.

Decorator Pattern'ın temel felsefesi, bir nesneye mevcut yapısını değiştirmeden dinamik olarak yeni sorumluluklar eklemektir. Bu, Açık/Kapalı Prensibi'ne (Open/Closed Principle) mükemmel bir şekilde uyar; yani, bir modül genişletmeye açık olmalı ancak değişiklik yapmaya kapalı olmalıdır. Aktivite kayıtları örneğimizde gördüğümüz gibi, bir kez temel servisimizi oluşturduktan sonra, kayıt özelliğini eklemek için mevcut kodu değiştirmemize gerek kalmadı, sadece yeni bir dekoratör sarmaladık. Bu yaklaşım, sadece aktivite kaydında değil, yetkilendirme, önbellekleme, performans izleme gibi birçok alanda da uygulanabilir ve yazılım geliştirme sürecini %70 veya daha fazla oranda basitleştirebilir.

Bu desenin sunduğu esneklik, bağımlılık enjeksiyonu konteynerleriyle birleştiğinde daha da güçlenir. Uygulamanın farklı katmanları arasında sağlam ve sürdürülebilir bir iletişim kurarak, temiz mimari prensiplerine ulaşmanın anahtarlarından biri haline gelir. Unutmayın, iyi bir mimari, değişime hızlı ve güvenli bir şekilde adapte olabilen bir mimaridir. Decorator Pattern, bu adaptasyonu sağlamak için bize güçlü bir araç sunar.

Sıkça Sorulan Sorular (SSS)

1. Decorator Pattern ile AOP (Aspect-Oriented Programming) arasındaki temel fark nedir?

   Decorator Pattern ve AOP, çapraz kesen endişeleri (logging, caching vb.) ana iş mantığından ayırma konusunda benzer hedeflere sahiptir. Ancak uygulama biçimleri farklıdır. Decorator, çalışma zamanında nesneleri sarmalayarak (kompozisyon) ek davranışlar ekler ve kod seviyesinde soyutlamalarla çalışır. AOP ise genellikle derleme zamanı veya çalışma zamanı vekil (proxy) oluşturma teknikleri kullanarak, kodun belirli "birleşme noktalarına" (join points) otomatik olarak ek davranışları "serpiştirir" (weaving). AOP daha geniş bir kapsama sahip olabilir ve genellikle daha az manuel yapılandırma gerektirir, ancak öğrenme eğrisi daha dik olabilir. Decorator, daha basit ve doğrudan bir yaklaşımdır.

2. Decorator Pattern kullanmak performansı olumsuz etkiler mi?

   Her soyutlama katmanı gibi Decorator Pattern da teorik olarak küçük bir performans ek yükü getirebilir (ek nesne oluşturma, sanal metod çağrıları). Ancak çoğu modern uygulamada ve donanımda bu ek yükler genellikle ihmal edilebilir düzeydedir ve elde edilen mimari faydalar (kod tekrarını azaltma, bakım kolaylığı, esneklik, test edilebilirlik) bu maliyetten çok daha değerlidir. Performansın aşırı kritik olduğu senaryolarda dikkatli bir analiz ve gerekirse alternatif yaklaşımlar düşünülmelidir.

3. Hangi durumlarda Decorator yerine miras (inheritance) kullanmalıyım?

   Eğer bir sınıfın davranışını değiştirmek veya genişletmek istediğinizde, sadece birkaç sabit varyasyonunuz varsa ve bu varyasyonların sayısı gelecekte pek değişmeyecekse, basit kalıtım yeterli olabilir. Decorator Pattern, özellikle çok sayıda farklı kombinasyonun dinamik olarak oluşturulması gerektiği veya mevcut kodu değiştirmeden yeni özelliklerin eklenmesi gerektiği durumlarda parlar. Kalıtım genellikle "bir şeydir" (is-a) ilişkisini ifade ederken, Decorator "bir şeyi sarar" (wraps-a) ilişkisini ifade eder ve daha fazla esneklik sunar.

4. Decorator Pattern'ın alternatifi olarak başka hangi tasarım desenleri düşünülebilir?

   Çapraz kesen endişelerin yönetiminde Decorator Pattern'a alternatif olarak Chain of Responsibility, Proxy Pattern veya Facade Pattern gibi diğer yapısal desenler belirli senaryolarda kullanılabilir. Ancak aktivite kaydı gibi birincil iş mantığını değiştirmeden ek özellikler ekleme konusunda Decorator oldukça özelleşmiş ve etkilidir. Ayrıca daha önce bahsedildiği gibi, Aspect-Oriented Programming (AOP) de güçlü bir alternatiftir.

5. Decorator Pattern, temiz mimari prensipleriyle nasıl uyum sağlar?

   Decorator Pattern, özellikle SOLID prensiplerinden Tek Sorumluluk Prensibi (Single Responsibility Principle - SRP) ve Açık/Kapalı Prensibi (Open/Closed Principle - OCP) ile mükemmel uyum sağlar. SRP'yi destekleyerek, her sınıfın tek bir sorumluluğu olmasını sağlar (örneğin, SomutSiparisServisi sadece sipariş işini yapar, kayıt işini değil). OCP'yi destekleyerek de, mevcut kodu değiştirmeden yeni işlevsellik eklememize olanak tanır. Bu da daha modüler, esnek ve bakımı kolay bir temiz mimari oluşturulmasına yardımcı olur.