Decorator Pattern

Decorator Pattern, geliştiricilerin bir nesneye orijinal sınıfını değiştirmeden dinamik olarak yeni davranışlar eklemesine olanak tanıyan yapısal bir tasarım modelidir. Bir nesneyi, aynı arayüzü korurken ek işlevsellik sağlayan başka bir nesnenin içine sararak çalışır.

Bu model, bir uygulamanın çok sayıda alt sınıf oluşturmadan davranışı esnek bir şekilde genişletmesi gerektiğinde kullanışlıdır. Günlük kaydı, önbelleğe alma, validation, biçimlendirme, yetkilendirme, sıkıştırma, şifreleme veya bildirim davranışı gibi özelliklerin mevcut bir nesnenin etrafına eklenmesine izin vererek temiz nesne yönelimli tasarımı destekler.

Giriş

Bu Design Patterns serisinin önceki makalesinde Adapter Pattern'yu tartışmıştık. Adapter, iki sınıf veya sistemin uyumsuz arayüzlere sahip olduğu ve birlikte çalışması için bir köprüye ihtiyaç duyduğu durumlarda kullanılır.

Decorator Pattern aynı zamanda yapısal bir tasarım modelidir ancak farklı bir sorunu çözer. Decorator, bir arayüzü değiştirmek yerine aynı arayüzü korur ve orijinal nesnenin çevresine ekstra davranışlar ekler.

Gerçek yazılım projelerinde geliştiricilerin genellikle kaynak kodlarını değiştirmeden mevcut sınıflara özellikler eklemeleri gerekir. Örneğin, bir hizmetin günlüğe kaydetmeye, önbelleğe almaya, validation'ya veya erişim kontrolüne ihtiyacı olabilir. Tüm bu özelliklerin doğrudan orijinal sınıfa eklenmesi, onu büyük ve bakımı zor hale getirebilir. Decorator Pattern, ekstra davranışların ayrı olarak eklenmesine olanak tanırken orijinal sınıfa odaklanılmasına yardımcı olur.

Decorator Pattern Nedir?

Decorator Pattern, orijinal davranışın öncesine, sonrasına veya çevresine yeni davranış eklemek için bir nesneyi başka bir nesneyle saran bir tasarım desenidir. Sarma nesnesine dekoratör denir.

Önemli fikir, dekoratörün sardığı nesneyle aynı arayüzü uygulamasıdır. Bu, müşteri kodunun orijinal nesneyi veya dekore edilmiş nesneyi aynı şekilde kullanabileceği anlamına gelir.

Örneğin, bir uygulamanın gönderme yöntemine sahip bir bildirim göndereni varsa, bir günlük dekoratörü de aynı gönderme yöntemini uygulayabilir. Bu yöntemin içinde mesajı günlüğe kaydedebilir ve ardından orijinal göndereni arayabilir.

Gerçek Hayattan Decorator Örneği

Gerçek hayattaki bir dekorasyon örneği, sade bir kahveye özellikler eklemektir. Sade bir kahve süt, şeker, çikolata veya krema ile süslenebilir. Temel içecek kahve olarak kalır, ancak her dekorasyon ekstra bir şey katar.

Yazılımda da aynı fikir geçerlidir. Temel bir nesne, dışarıdan orijinal nesne gibi davranmaya devam ederken yeni davranışlar ekleyen bir veya daha fazla dekoratörle sarılabilir.

Bu, olası her kombinasyon için ayrı bir alt sınıf oluşturmadan özellikleri birleştirmeyi mümkün kılar.

Decorator Pattern Neden Önemlidir?

Decorator Pattern önemlidir çünkü geliştiricilerin mevcut kodu değiştirmeden davranışı genişletmelerine yardımcı olur. Bu, yazılımın genişletmeye açık ancak değişiklik için kapalı olması gerektiğini söyleyen Açık Kapalı Prensibini destekler.

Geliştiriciler, her yeni özelliğe ihtiyaç duyulduğunda orijinal sınıfı değiştirmek yerine yeni bir dekoratör oluşturabilir. Bu, mevcut davranışı bozma riskini azaltır ve kodun test edilmesini kolaylaştırır.

Decorator, davranışın dinamik olarak birleştirilmesi gerektiğinde de kullanışlıdır. Örneğin, bir dosya depolama hizmeti, yapılandırmaya bağlı olarak günlük kaydı, önbellekleme ve şifreleme ile donatılabilir.

Decorator Pattern Olmadan Sorun

Bildirim gönderen bir uygulama düşünün. İlk başta, bildirimi gönderen yalnızca mesaj gönderir. Daha sonra uygulamanın günlüğe kaydedilmesi gerekiyor. O zaman validation'ya ihtiyacı var. Daha sonra yeniden deneme mantığına ihtiyaç duyar. Daha sonra performansın izlenmesi gerekiyor.

Decorator Pattern olmadan geliştiriciler bu sorumlulukların tümünü doğrudan orijinal bildirim sınıfına ekleyebilir:

class EmailNotificationSender
{
    public function send(string $recipient, string $message): bool
    {
        // Validate message
        // Log sending attempt
        // Send email
        // Retry on failure
        // Record performance metrics
        return true;
    }
}

Bu sınıfın artık çok fazla sorumluluğu var. Yalnızca e-posta göndermekle kalmıyor. Aynı zamanda doğrulama, günlüğe kaydetme, yeniden deneme ve izleme işlemlerini de gerçekleştirir.

Decorator Pattern, her ek davranışı kendi sarmalayıcı sınıfına ayırarak bu sorunu çözer.

Temel Decorator Pattern Yapısı

Decorator Pattern genellikle aşağıdaki parçaları içerir:

Bileşen arayüzü: Hem orijinal nesne hem de dekoratörler tarafından kullanılan ortak davranışı tanımlar.
Somut bileşen: Temel davranışı sağlayan orijinal nesne.
Temel dekoratör: Bir bileşen nesnesini saklayan ve aynı arayüzü uygulayan bir sarmalayıcı.
Beton dekoratörleri: Sarılmış nesneyi çağırmadan önce veya sonra belirli davranışlar ekleyen sınıflar.

Bu yapı dekoratörlerin farklı şekillerde istiflenmesine ve birleştirilmesine olanak sağlar.

PHP'da Temel Decorator Örneği

Aşağıdaki örnek, bildirimler için basit bir Decorator Pattern uygulamasını göstermektedir:

interface NotificationSender
{
    public function send(string $recipient, string $message): bool;
}

class EmailNotificationSender implements NotificationSender
{
    public function send(string $recipient, string $message): bool
    {
        // Send email notification
        return true;
    }
}

abstract class NotificationSenderDecorator implements NotificationSender
{
    public function __construct(
        protected NotificationSender $sender
    ) {
    }
}

class LoggingNotificationDecorator extends NotificationSenderDecorator
{
    public function send(string $recipient, string $message): bool
    {
        echo 'Logging notification before sending.' . PHP_EOL;

        return $this->sender->send($recipient, $message);
    }
}

Bu örnekte, LoggingNotificationDecorator başka bir NotificationSender'ı sarar ve bildirimi göndermeden önce günlük kaydı davranışı ekler.

Decoratorü Kullanmak

Dekore edilen nesne aynı arayüz aracılığıyla kullanılabilir:

$sender = new EmailNotificationSender();

$senderWithLogging = new LoggingNotificationDecorator($sender);

$senderWithLogging->send('user@example.com', 'Welcome to our platform.');

client code çağrıları da aynı şekilde gönderilir. Nesnenin orijinal gönderici mi yoksa dekore edilmiş gönderici mi olduğunu bilmesine gerek yoktur.

Bu, Decorator Pattern'nun temel güçlü yönlerinden biridir. Nesnenin kullanım şeklini değiştirmeden davranış ekler.

Birden Fazla Decorator Ekleme

Bir dekoratör başka bir dekoratörü sarabilir. Bu, birden fazla davranışın dinamik olarak birleştirilmesine olanak tanır.

Örneğin, validation ve günlük dekoratörlerini aynı bildirim göndericisinin etrafına ekleyebiliriz:

class ValidationNotificationDecorator extends NotificationSenderDecorator
{
    public function send(string $recipient, string $message): bool
    {
        if (empty($recipient)) {
            throw new InvalidArgumentException('Recipient is required.');
        }

        if (empty($message)) {
            throw new InvalidArgumentException('Message is required.');
        }

        return $this->sender->send($recipient, $message);
    }
}

class RetryNotificationDecorator extends NotificationSenderDecorator
{
    public function send(string $recipient, string $message): bool
    {
        try {
            return $this->sender->send($recipient, $message);
        } catch (Throwable $exception) {
            return $this->sender->send($recipient, $message);
        }
    }
}

Artık nesne birden çok katmanla süslenebilir:

$sender = new EmailNotificationSender();

$sender = new ValidationNotificationDecorator($sender);
$sender = new LoggingNotificationDecorator($sender);
$sender = new RetryNotificationDecorator($sender);

$sender->send('user@example.com', 'Your order has been shipped.');

Her dekoratör, aynı NotificationSender arayüzünü korurken belirli bir sorumluluk ekler.

Decorator Pattern ve Bileşimi

Decorator Pattern kompozisyona dayalıdır. Orijinal sınıfı kalıtım yoluyla genişletmek yerine, dekoratör başka bir nesne içerir ve delegeler ona çalışır.

Bu önemlidir çünkü kompozisyon genellikle kalıtımdan daha esnektir. Kalıtımla, birçok davranış kombinasyonunun eklenmesi birçok alt sınıfa yol açabilir. Decoratorlerle davranışlar, nesnelerin sarılması yoluyla dinamik olarak birleştirilebilir.

Bu, ortak nesne yönelimli prensibi destekler: kalıtım yerine kompozisyonu tercih edin.

Decorator Pattern ve Kalıtım

Kalıtım, alt sınıflar oluşturarak davranış ekleyebilir, ancak birçok özellik kombinasyonuna ihtiyaç duyulduğunda bu zorlaşır.

Örneğin, isteğe bağlı günlük kaydı, önbelleğe alma, validation, yeniden deneme, şifreleme ve izleme özelliklerine sahip bir bildirim göndericisini hayal edin. Kalıtımın kullanılması, LoggedEmailSender, CachedEmailSender, ValidatedEmailSender, LoggedCachedEmailSender gibi birçok sınıfın ve daha birçok kombinasyonun kullanılmasını gerektirebilir.

Decorator, her özelliğin gerektiğinde birleştirilebilecek ayrı bir pakete yerleştirilmesine izin vererek bu sorunu önler.

Gerçek Dünyadan Örnek: Önbelleğe Alma Decoratorü

Önbelleğe alma, Decorator Pattern için yaygın bir kullanım durumudur. Bir hizmet, yavaş bir API veya database'dan veri alabilir. Bir önbellek dekoratörü sonucu saklayabilir ve gelecekteki çağrılarda önbelleğe alınmış verileri döndürebilir.

interface ProductProvider
{
    public function find(int $id): array;
}

class ApiProductProvider implements ProductProvider
{
    public function find(int $id): array
    {
        // Fetch product from external API
        return [
            'id' => $id,
            'name' => 'Laptop',
        ];
    }
}

class CachedProductProvider implements ProductProvider
{
    private array $cache = [];

    public function __construct(
        private ProductProvider $provider
    ) {
    }

    public function find(int $id): array
    {
        if (!isset($this->cache[$id])) {
            $this->cache[$id] = $this->provider->find($id);
        }

        return $this->cache[$id];
    }
}

CachedProductProvider, orijinal ürün sağlayıcısını dekore eder ve ApiProductProvider'ı değiştirmeden önbelleğe alma davranışı ekler.

Gerçek Dünyadan Örnek: Günlük Decoratorü

Günlüğe kaydetme dekoratörleri, geliştiricilerin günlük kodunu doğrudan iş sınıflarına eklemeden işlemleri kaydetmek istediklerinde kullanışlıdır.

class LoggedProductProvider implements ProductProvider
{
    public function __construct(
        private ProductProvider $provider,
        private LoggerInterface $logger
    ) {
    }

    public function find(int $id): array
    {
        $this->logger->info('Finding product', ['id' => $id]);

        $product = $this->provider->find($id);

        $this->logger->info('Product found', ['id' => $id]);

        return $product;
    }
}

Bu, orijinal sağlayıcının ürünleri almaya odaklanmasını sağlarken, dekoratör günlüğe kaydetme işlemlerini gerçekleştirir.

Gerçek Dünyadan Örnek: Yetkilendirme Decoratorü

Yetkilendirme dekoratörü, bir işlemin devam etmesine izin vermeden önce izinleri kontrol edebilir.

interface ReportExporter
{
    public function export(array $data): string;
}

class PdfReportExporter implements ReportExporter
{
    public function export(array $data): string
    {
        return 'PDF report exported';
    }
}

class AuthorizedReportExporter implements ReportExporter
{
    public function __construct(
        private ReportExporter $exporter,
        private User $user
    ) {
    }

    public function export(array $data): string
    {
        if (!$this->user->can('export_reports')) {
            throw new RuntimeException('User is not allowed to export reports.');
        }

        return $this->exporter->export($data);
    }
}

Yetkilendirme mantığı PDF dışa aktarma mantığından ayrılmıştır. Bu, sorumlulukların ayrılmasını iyileştirir.

Gerçek Dünyadan Örnek: Sıkıştırma ve Şifreleme

Decorator Pattern, dosyaları veya veri akışlarını işlerken de kullanışlıdır. Temel bir dosya yazıcısı sıkıştırma ve şifreleme ile donatılabilir.

interface FileWriter
{
    public function write(string $content): string;
}

class PlainFileWriter implements FileWriter
{
    public function write(string $content): string
    {
        return $content;
    }
}

class CompressionFileWriter implements FileWriter
{
    public function __construct(
        private FileWriter $writer
    ) {
    }

    public function write(string $content): string
    {
        $compressed = gzcompress($content);

        return $this->writer->write($compressed);
    }
}

class EncryptionFileWriter implements FileWriter
{
    public function __construct(
        private FileWriter $writer
    ) {
    }

    public function write(string $content): string
    {
        $encrypted = base64_encode($content);

        return $this->writer->write($encrypted);
    }
}

Uygulama, gerekli davranışa bağlı olarak bu dekoratörleri birleştirebilir.

Laravel'da Decorator Pattern

Laravel uygulamalarında Decorator Pattern, hizmetler, depolar, API istemcileri, ödeme ağ geçitleri, bildirim gönderenleri ve önbellek katmanlarıyla birlikte kullanılabilir.

Örneğin, bir Laravel uygulaması bir ProductRepository arayüzüne sahip olabilir. Ana depo, database'dan ürünleri getirirken, bir önbellek dekoratörü etrafına önbellek davranışı ekler.

$this->app->bind(ProductRepository::class, function ($app) {
    $repository = new DatabaseProductRepository();

    return new CachedProductRepository($repository, $app->make(CacheRepository::class));
});

Bu, önbelleğe alma şeffaf bir şekilde eklenirken uygulamanın ProductRepository'yi normal şekilde kullanmasına olanak tanır.

Symfony'da Decorator Pattern

Symfony, bağımlılık enjeksiyon kapsayıcısı aracılığıyla hizmet dekorasyonu için güçlü bir desteğe sahiptir. Geliştiriciler, orijinal hizmeti değiştirmeden, günlüğe kaydetme, önbelleğe alma, izleme veya güvenlik kontrolleri gibi davranışlar eklemek için hizmetleri dekore edebilir.

Bu, Decorator Pattern'yu Symfony uygulamalarında çok pratik hale getirir. Servis kapsayıcısı, bir servisi başka bir dekoratör servisiyle otomatik olarak sarabilir.

Bu, kesişen konuların temiz bir şekilde eklenmesi gereken büyük uygulamalarda kullanışlıdır.

Decorator Pattern ve Ara Yazılım

Web çerçevelerindeki ara yazılım kavramsal olarak Decorator Pattern ile ilişkilidir. Ara yazılım, istek işlemeyi sarar ve bir sonraki katmanın yürütülmesinden önce veya sonra davranış ekler.

Örneğin, ara katman yazılımı kimlik doğrulama, günlük kaydı, hız sınırlama, CORS işleme veya dönüşüm isteği ekleyebilir. Her ara yazılım katmanı bir sonraki işlemi sarar ve ek davranışa katkıda bulunur.

Ara katman yazılımı her zaman tam olarak klasik Decorator Pattern gibi uygulanmasa da, sarma davranışı fikri çok benzer.

Decorator Pattern ve Kesişen Endişeler

Kesişen kaygılar, bir uygulamanın birçok bölümünü etkileyen davranışlardır. Örnekler arasında günlüğe kaydetme, önbelleğe alma, yetkilendirme, validation, izleme, yeniden deneme mantığı ve hata işleme yer alır.

Bu kaygılar her hizmete doğrudan eklenirse kod kopyalanır ve bakımı zorlaşır. Decorator Pattern bu endişelerin yeniden kullanılabilir paketlere ayrılmasına olanak tanır.

Bu, clean architecture'yu iyileştirir ve iş sınıflarının ana sorumluluklarına odaklanmasını sağlar.

Decorator Pattern vs Adapter Pattern

Decorator Pattern ve Adapter Pattern'nun her ikisi de sarmalayıcılar kullanır ancak farklı hedefleri vardır.

Adapter Pattern, bir nesnenin arayüzünü değiştirerek farklı bir arayüz bekleyen kodla çalışabilmesini sağlar. Esas olarak uyumlulukla ilgilidir.

Decorator Pattern aynı arayüzü korur ancak nesnenin çevresine yeni davranışlar ekler. Esas olarak uzatma ile ilgilidir.

Kısacası Adapter bir nesneye nasıl erişildiğini değiştirirken Decorator arayüzü değiştirmeden davranış ekler.

Decorator Pattern vs Facade Pattern

Facade Pattern, karmaşık bir alt sisteme basit bir arayüz sağlar. Karmaşıklığı daha basit bir API'nun arkasına gizler.

Decorator Pattern, aynı arayüzü korurken bir nesneye davranış ekler. Bir alt sistemi mutlaka basitleştirmez. Bunun yerine mevcut bir nesneyi dinamik olarak genişletir.

Kısacası, Facade erişimi basitleştirirken Decorator davranışı geliştirir.

Decorator Pattern ve Proxy Deseni Karşılaştırması

Proxy Kalıbı başka bir nesneye erişimi kontrol eder. Tembel yükleme, erişim kontrolü, uzaktan iletişim veya önbelleğe alma ekleyebilir. Decorator Pattern aynı arayüzü korurken davranış ekler.

Bu desenler benzer görünebilir çünkü her ikisi de başka bir nesneyi sarmaktadır. Fark çoğunlukla niyettedir. Proxy erişimi kontrol ederken Decorator sorumluluklar ekler.

Decorator Pattern'nun Faydaları

Decorator Pattern, nesne yönelimli yazılım tasarımında birçok fayda sağlar.

Ana faydalar şunları içerir:

Orijinal sınıfı değiştirmeden davranış ekler.
Açık Kapalı Prensibini destekler.
Birçok alt sınıfa olan ihtiyacı azaltır.
Davranışın dinamik olarak birleştirilmesini sağlar.
Sorumlulukların ayrılmasını geliştirir.
Arayüzler ve bağımlılık enjeksiyonu ile iyi çalışır.
Kesişen endişelerin izole edilmesine yardımcı olur.
Günlüğe kaydetme ve önbelleğe alma gibi özellikleri yeniden kullanılabilir hale getirir.

Bu avantajlar Decorator Pattern'yu özellikle orta ve büyük uygulamalarda kullanışlı kılmaktadır.

Decorator Pattern'nun dezavantajları

Decorator Pattern'nun dezavantajları da olabilir. Yapı iyi organize edilmemişse projede gezinmeyi zorlaştırabilecek birçok küçük sınıf oluşturabilir.

Diğer bir dezavantaj ise, bir nesne birçok katmanla sarıldığında hata ayıklamanın daha zor olabilmesidir. Geliştiricilerin davranışın tamamını anlamak için birkaç dekoratörün izini sürmesi gerekebilir.

Decoratorün sırası da önemli olabilir. Örneğin, önbelleğe almadan önce günlüğe kaydetme, günlüğe kaydetmeden önce önbelleğe almaya göre farklı sonuçlar üretebilir. Geliştiriciler dekoratörleri istiflerken dikkatli olmalıdır.

Decorator Pattern Ne Zaman Kullanılır?

Orijinal sınıflarını değiştirmeden nesnelere davranış eklemeniz gerektiğinde Decorator Pattern'yu kullanın.

Decorator Pattern şu durumlarda faydalıdır:

Bir hizmetin çevresine günlük kaydı, önbellekleme, validation veya yetkilendirme eklemek istiyorsunuz.
Birden çok isteğe bağlı davranışı dinamik olarak birleştirmeniz gerekir.
Çok sayıda alt sınıf oluşturmaktan kaçınmak istiyorsunuz.
Orijinal sınıfı odaklanmış ve temiz tutmak istiyorsunuz.
Ekstra davranış eklerken aynı arayüzü takip etmeniz gerekir.
Kesişen endişeleri business logicndan ayırmak istiyorsunuz.

Bu koşullar mevcutsa Decorator Pattern güçlü bir tasarım seçeneği olabilir.

Decorator Pattern Ne Zaman Kullanılmamalı?

Davranışın basit olduğu ve değişme ihtimalinin düşük olduğu durumlarda Decorator Pattern kullanmayın. Bir özelliğin doğrudan bir sınıfa eklenmesi açıksa ve sorumluluk sınırlarını aşmıyorsa dekoratöre gerek olmayabilir.

Aşağıdaki durumlarda Decorator Pattern'dan kaçının:

Nesnenin dinamik davranış uzantısına ihtiyacı yoktur.
Desen, gerçek değeri olmayan çok fazla sınıf ekliyor.
Aynı davranış yapılandırmayla daha basit bir şekilde ele alınabilir.
Decoratorlerin sırası kafa karıştırıcı hale geliyor.
Özellik doğal olarak orijinal sınıfın içine aittir.

Design Patterns kodu daha karmaşık değil, daha temiz hale getirmelidir.

Decorator Pattern ile Yapılan Yaygın Hatalar

Yaygın bir hata, dekoratördeki arayüzü değiştirmektir. Bir dekoratör genellikle sardığı nesneyle aynı arayüzü korumalıdır. Arayüzü değiştirirse aslında bir adaptör gibi davranıyor olabilir.

Bir diğer hata ise dekoratörlerin içine ilgisiz business logicnı koymaktır. Decoratorler, büyük hizmet sınıfları haline gelmemeli, belirli ekstra davranışlar eklemelidir.

Üçüncü bir hata, dekoratörlerin sırasını kontrol etmeden istiflemektir. Bazı dekoratörler diğerlerinden önce koşmalı ve sıra net olmalıdır.

Dördüncü hata ise her küçük özellik için dekoratörler oluşturmaktır. Özellik basitse ve sınıfa aitse dekoratöre gerek olmayabilir.

Decorator Pattern için En İyi Uygulamalar

Decorator Pattern'yu etkili bir şekilde kullanmak için geliştiricilerin dekoratörleri küçük, odaklanmış ve tutarlı tutması gerekir.

Yararlı en iyi uygulamalar şunları içerir:

Orijinal nesne ve dekoratörler tarafından paylaşılan net bir arayüz kullanın.
Her dekoratörün tek bir sorumluluğa odaklanmasını sağlayın.
Hizmetleri temiz bir şekilde sarmak için bağımlılık eklemeyi kullanın.
CachedProductProvider veya LoggedPaymentGateway gibi anlamlı adlar kullanın.
Birden fazla dekoratör kullanıldığında dekoratör sırasını net tutun.
Decoratorlerdeki genel arayüzü değiştirmekten kaçının.
Günlüğe kaydetme, önbelleğe alma ve yetkilendirme gibi kesişen konular için dekoratörleri kullanın.
Basit problemler için dekoratörleri aşırı kullanmayın.

Bu uygulamalar Decorator Pattern'nun bakımı kolay ve pratik kalmasına yardımcı olur.

Decorator Pattern Kullanmadan Önce Pratik Kontrol Listesi

Decorator Pattern'yu kullanmadan önce geliştiriciler şu soruları sorabilir:

Orijinal sınıfı değiştirmeden davranış eklemem gerekiyor mu?
Yeni davranış odaklanmış bir sarmalayıcıya ayrılabilir mi?
Dekore edilen nesne aynı arayüzü korumalı mı?
Bu çok fazla alt sınıftan kaçınacak mı?
Bu, kesişen endişeleri daha temiz hale getirecek mi?
Decoratorler güvenli bir şekilde birleştirilebilir mi?
Eklenen karmaşıklık esnekliğe değer mi?

Bu soruların birçoğunun cevabı evet ise Decorator Pattern iyi bir tasarım tercihi olabilir.

Sonuç

Decorator Pattern, geliştiricilerin orijinal sınıflarını değiştirmeden nesnelere dinamik olarak davranış eklemelerine olanak tanıyan yapısal bir tasarım modelidir. Bir nesneyi aynı arayüzü uygulayan ve ekstra işlevsellik ekleyen başka bir nesneyle sararak çalışır.

Decorator Pattern günlüğe kaydetme, önbelleğe alma, validation, yetkilendirme, yeniden deneme mantığı, izleme, sıkıştırma, şifreleme ve diğer kesişen konular için kullanışlıdır. clean code, kompozisyon, bağımlılık enjeksiyonu ve Açık Kapalı Prensibini destekler.

Ancak Decorator dikkatli kullanılmalıdır. Çok fazla dekoratör, hata ayıklamanın ve nesne akışının anlaşılmasını zorlaştırabilir. Doğru uygulandığında Decorator Pattern esnek, bakımı yapılabilir ve genişletilebilir nesne yönelimli yazılım oluşturmaya yönelik güçlü bir araçtır.

Decorator Pattern

Decorator Pattern

Giriş