Decorator Pattern

Decorator Pattern عبارة عن نمط تصميم هيكلي يسمح للمطورين بإضافة سلوك جديد إلى كائن ديناميكيًا دون تغيير class الأصلي. إنه يعمل عن طريق تغليف كائن داخل كائن آخر يوفر وظائف إضافية مع الاحتفاظ بنفس interface.

يكون هذا النمط مفيدًا عندما يحتاج التطبيق إلى توسيع السلوك بطريقة مرنة دون إنشاء العديد من subclasses. وهو يدعم التصميم النظيف الموجه للكائنات من خلال السماح بإضافة ميزات مثل التسجيل أو التخزين المؤقت أو التحقق من الصحة أو التنسيق أو الترخيص أو الضغط أو التشفير أو سلوك الإعلام حول كائن موجود.

مقدمة

في المقالة السابقة من سلسلة Design Patterns، ناقشنا Adapter Pattern. يتم استخدام Adapter عندما يكون هناك classes أو interfaces غير متوافقة وتحتاج إلى جسر للعمل معًا.

يعد Decorator Pattern أيضًا نمط تصميم هيكليًا، ولكنه يحل مشكلة مختلفة. بدلاً من تغيير interface، يحتفظ Decorator بنفس interface ويضيف سلوكًا إضافيًا حول الكائن الأصلي.

في مشاريع البرامج الحقيقية، غالبًا ما يحتاج المطورون إلى إضافة ميزات إلى classes الموجودة دون تعديل كود المصدر الخاص بهم. على سبيل المثال، قد تحتاج الخدمة إلى التسجيل أو التخزين المؤقت أو التحقق من الصحة أو التحكم في الوصول. يمكن أن تؤدي إضافة كل هذه الميزات مباشرةً إلى class الأصلي إلى جعلها كبيرة الحجم وصعبة الصيانة. يساعد Decorator Pattern في الحفاظ على تركيز class الأصلي مع السماح بإضافة سلوك إضافي بشكل منفصل.

ما هو Decorator Pattern؟

Decorator Pattern هو نمط تصميم يقوم بتغليف كائن بكائن آخر لإضافة سلوك جديد قبل السلوك الأصلي أو بعده أو حوله. يسمى كائن التغليف decorator.

الفكرة المهمة هي أن decorator ينفذ نفس interface مثل الكائن الذي يغلّفه. وهذا يعني أن كود العميل يمكنه استخدام الكائن الأصلي أو الكائن المزخرف بنفس الطريقة.

على سبيل المثال، إذا كان التطبيق يحتوي على مرسل إعلام بأسلوب إرسال، فيمكن لـ decorator أيضًا تنفيذ نفس أسلوب الإرسال. داخل هذه الطريقة، يمكنه تسجيل الرسالة ثم الاتصال بالمرسل الأصلي.

مثال واقعي لـ Decorator

أحد الأمثلة الواقعية للديكور هو إضافة ميزات إلى القهوة الأساسية. يمكن تزيين القهوة البسيطة بالحليب أو السكر أو الشوكولاتة أو الكريمة. يظل المشروب الأساسي هو القهوة، لكن كل ديكور يضيف شيئًا إضافيًا.

في البرمجيات، تنطبق نفس الفكرة. يمكن تغليف الكائن الأساسي بواحد أو أكثر من decorator التي تضيف سلوكًا جديدًا بينما تظل تتصرف مثل الكائن الأصلي من الخارج.

وهذا يجعل من الممكن دمج الميزات دون إنشاء subclass منفصل لكل مجموعة ممكنة.

لماذا يعد Decorator Pattern مهمًا

يعد Decorator Pattern مهمًا لأنه يساعد المطورين على توسيع السلوك دون تعديل الكود الموجودة. وهذا يدعم المبدأ المفتوح المغلق، والذي ينص على أن البرنامج يجب أن يكون مفتوحًا للتوسيع ولكنه مغلق للتعديل.

بدلاً من تغيير class الأصلي في كل مرة تكون هناك حاجة إلى ميزة جديدة، يمكن للمطورين إنشاء decorator جديد. وهذا يقلل من خطر كسر السلوك الحالي ويجعل اختبار الكود أسهل.

يعد Decorator مفيدًا أيضًا عندما يلزم دمج السلوك ديناميكيًا. على سبيل المثال، قد يتم تزيين خدمة تخزين الملفات بالتسجيل والتخزين المؤقت والتشفير اعتمادًا على التكوين.

مشكلة بدون Decorator Pattern

تخيل تطبيقًا يرسل إشعارات. في البداية، يقوم مرسل الإشعارات بإرسال الرسائل فقط. وفي وقت لاحق، يحتاج التطبيق إلى التسجيل. ثم يحتاج إلى التحقق من الصحة. ثم يحتاج إلى منطق إعادة المحاولة. ثم يحتاج إلى مراقبة الأداء.

بدون Decorator Pattern، يمكن للمطورين إضافة كل هذه المسؤوليات مباشرةً إلى الإشعار الأصلي class:

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;
    }
}

لدى class الآن الكثير من المسؤوليات. لا يقتصر الأمر على إرسال رسائل البريد الإلكتروني. كما يتم أيضًا التحقق من الصحة والتسجيل وإعادة المحاولة والمراقبة.

يحل Decorator Pattern هذه المشكلة عن طريق فصل كل سلوك إضافي في غلافه الخاص class.

هيكل Decorator Pattern الأساسي

يتضمن Decorator Pattern عادةً الأجزاء التالية:

• المكون interface: يحدد السلوك الشائع المستخدم بواسطة كل من الكائن الأصلي وdecorators.
• مكون Concrete: الكائن الأصلي الذي يوفر السلوك الأساسي.
• Base decorator: برنامج تضمين يقوم بتخزين كائن مكون وتنفيذ نفس interface.
• Concrete decorators: Classes التي تضيف سلوكًا محددًا قبل أو بعد استدعاء الكائن الملتف.

يسمح هذا الهيكل بتكديس decorators ودمجها بطرق مختلفة.

مثال Decorator الأساسي في PHP

يوضح المثال التالي تطبيق Decorator Pattern البسيط للإشعارات:

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);
    }
}

في هذا المثال، يقوم LoggingNotificationDecorator بتغليف NotificationSender آخر وإضافة سلوك التسجيل قبل إرسال الإشعار.

باستخدام Decorator

يمكن استخدام الكائن المزخرف من خلال نفس interface:

$sender = new EmailNotificationSender();

$senderWithLogging = new LoggingNotificationDecorator($sender);

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

يتم إرسال مكالمات كود العميل بنفس الطريقة. لا يحتاج إلى معرفة ما إذا كان الكائن هو المرسل الأصلي أم المرسل المزخرف.

هذه هي إحدى نقاط القوة الرئيسية في Decorator Pattern. يضيف السلوك دون تغيير كيفية استخدام الكائن.

إضافة عدة Decorators

يمكن لواحد decorator أن يغلف decorator آخر. وهذا يسمح بدمج سلوكيات متعددة ديناميكيًا.

على سبيل المثال، يمكننا إضافة التحقق من الصحة وتسجيل decorators حول نفس مرسل الإشعارات:

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);
        }
    }
}

الآن يمكن تزيين الكائن بطبقات متعددة:

$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.');

يضيف كل decorator مسؤولية محددة مع الاحتفاظ بنفس NotificationSender interface.

Decorator Pattern والتكوين

يعتمد Decorator Pattern على التكوين. بدلاً من توسيع class الأصلي عبر inheritance، يحتوي decorator على كائن آخر ويقوم بتفويض العمل إليه.

وهذا أمر مهم لأن التركيب غالبًا ما يكون أكثر مرونة من inheritance. باستخدام inheritance، يمكن أن تؤدي إضافة العديد من مجموعات السلوك إلى العديد من subclasses. باستخدام decorators، يمكن دمج السلوك ديناميكيًا عن طريق التفاف الكائنات.

وهذا يدعم المبدأ العام الموجه للكائنات: تفضيل التركيب على inheritance.

Decorator Pattern مقابل Inheritance

يمكن لـ Inheritance إضافة سلوك عن طريق إنشاء classes، ولكن يصبح الأمر صعبًا عند الحاجة إلى العديد من مجموعات الميزات.

على سبيل المثال، تخيل مرسل إعلام مع التسجيل الاختياري والتخزين المؤقت والتحقق من الصحة وإعادة المحاولة والتشفير والمراقبة. قد يتطلب استخدام inheritance العديد من classes مثل LoggedEmailSender وCachedEmailSender وValidatedEmailSender وLoggedCachedEmailSender والعديد من المجموعات الأخرى.

يتجنب Decorator هذه المشكلة عن طريق السماح بوضع كل ميزة في غلاف منفصل يمكن دمجه حسب الحاجة.

مثال من العالم الحقيقي: التخزين المؤقت Decorator

يعد التخزين المؤقت حالة استخدام شائعة لـ Decorator Pattern. قد تقوم الخدمة بجلب البيانات من قاعدة البيانات أو قاعدة البيانات API البطيئة. يمكن للتخزين المؤقت decorator تخزين النتيجة وإرجاع البيانات المخزنة مؤقتًا في المكالمات المستقبلية.

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 بتزيين موفر المنتج الأصلي ويضيف سلوك التخزين المؤقت دون تعديل ApiProductProvider.

مثال من العالم الحقيقي: تسجيل Decorator

يعد تسجيل decorators مفيدًا عندما يرغب المطورون في تسجيل العمليات دون إضافة رمز التسجيل مباشرةً إلى الأعمال classes.

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;
    }
}

يؤدي هذا إلى إبقاء الموفر الأصلي يركز على جلب المنتجات بينما يقوم decorator بمعالجة التسجيل.

مثال من العالم الحقيقي: التفويض Decorator

يمكن للتفويض decorator التحقق من الأذونات قبل السماح بمواصلة العملية.

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);
    }
}

يتم فصل منطق الترخيص عن منطق تصدير PDF. وهذا يحسن الفصل بين المسؤوليات.

مثال من العالم الحقيقي: الضغط والتشفير

يعد Decorator Pattern مفيدًا أيضًا عند معالجة الملفات أو تدفقات البيانات. يمكن تزيين كاتب الملفات الأساسي بالضغط والتشفير.

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);
    }
}

يمكن للتطبيق دمج decorators اعتمادًا على السلوك المطلوب.

Decorator Pattern في Laravel

في تطبيقات Laravel، يمكن استخدام Decorator Pattern مع الخدمات وعملاء repositories وAPI وبوابات الدفع ومرسلي الإشعارات وطبقات ذاكرة التخزين المؤقت.

على سبيل المثال، قد يحتوي تطبيق Laravel على ProductRepository interface. يقوم repository الرئيسي بجلب المنتجات من قاعدة البيانات، بينما يضيف التخزين المؤقت decorator سلوك ذاكرة التخزين المؤقت حوله.

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

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

يسمح هذا للتطبيق باستخدام ProductRepository بشكل طبيعي أثناء إضافة التخزين المؤقت بشفافية.

Decorator Pattern في Symfony

يتمتع Symfony بدعم قوي لتزيين الخدمة من خلال dependency injection container. يمكن للمطورين تزيين الخدمات لإضافة سلوك مثل التسجيل أو التخزين المؤقت أو التتبع أو عمليات التحقق من الأمان دون تعديل الخدمة الأصلية.

وهذا يجعل Decorator Pattern عمليًا جدًا في تطبيقات Symfony. يمكن لـ service container التفاف خدمة واحدة تلقائيًا مع خدمة decorator أخرى.

يعد هذا مفيدًا في التطبيقات الكبيرة حيث يجب إضافة الاهتمامات الشاملة بشكل واضح.

Decorator Pattern والبرمجيات الوسيطة

ترتبط البرامج الوسيطة في أطر عمل الويب من الناحية النظرية بـ Decorator Pattern. تقوم البرامج الوسيطة بتغليف معالجة request وتضيف السلوك قبل أو بعد تنفيذ الطبقة التالية.

على سبيل المثال، يمكن للبرامج الوسيطة إضافة المصادقة أو التسجيل أو تحديد المعدل أو معالجة CORS أو تحويل request. تقوم كل طبقة من البرمجيات الوسيطة بتغليف العملية التالية وتساهم في سلوك إضافي.

على الرغم من أن البرامج الوسيطة لا يتم تنفيذها دائمًا تمامًا مثل classic Decorator Pattern، إلا أن فكرة سلوك الالتفاف متشابهة جدًا.

Decorator Pattern والمخاوف الشاملة

الاهتمامات الشاملة هي السلوكيات التي تؤثر على أجزاء كثيرة من التطبيق. تشمل الأمثلة التسجيل والتخزين المؤقت والترخيص والتحقق من الصحة والمراقبة ومنطق إعادة المحاولة ومعالجة الأخطاء.

إذا تمت إضافة هذه المخاوف مباشرة إلى كل خدمة، يصبح الكود مكررًا ويصعب صيانته. يسمح Decorator Pattern بفصل هذه المخاوف إلى أغلفة قابلة لإعادة الاستخدام.

يؤدي ذلك إلى تحسين البنية النظيفة والحفاظ على تركيز الأعمال classes على مسؤوليتها الرئيسية.

Decorator Pattern مقابل Adapter Pattern

يستخدم كل من Decorator Pattern وAdapter Pattern الأغلفة، لكن أهدافهما مختلفة.

يقوم Adapter Pattern بتغيير interface للكائن حتى يتمكن من العمل مع الكود الذي تتوقع interface مختلفةة. يتعلق الأمر بشكل أساسي بالتوافق.

يحتفظ Decorator Pattern بنفس interface ولكنه يضيف سلوكًا جديدًا حول الكائن. يتعلق الأمر بشكل أساسي بالتمديد.

باختصار، يغير Adapter كيفية الوصول إلى الكائن، بينما يضيف Decorator السلوك دون تغيير interface.

Decorator Pattern مقابل Facade Pattern

يوفر Facade Pattern interface بسيطًا لنظام فرعي معقد. إنه يخفي التعقيد خلف API الأبسط.

يضيف Decorator Pattern سلوكًا إلى كائن مع الاحتفاظ بنفس interface. لا يؤدي بالضرورة إلى تبسيط النظام الفرعي. بدلاً من ذلك، يقوم بتوسيع كائن موجود بشكل حيوي.

باختصار، يعمل Facade على تبسيط الوصول، بينما يعمل Decorator على تحسين السلوك.

Decorator Pattern مقابل نمط الوكيل

يتحكم نمط الوكيل في الوصول إلى كائن آخر. قد يضيف التحميل البطيء أو التحكم في الوصول أو الاتصال عن بعد أو التخزين المؤقت. يضيف Decorator Pattern السلوك مع الحفاظ على نفس interface.

يمكن أن تبدو هذه الأنماط متشابهة لأن كلاهما يلتف حول كائن آخر. الفرق هو في الغالب في النية. يتحكم الوكيل في الوصول، بينما يضيف Decorator المسؤوليات.

فوائد Decorator Pattern

يوفر Decorator Pattern العديد من الفوائد في تصميم البرامج الموجهة للكائنات.

تشمل الفوائد الرئيسية ما يلي:

• إضافة سلوك دون تعديل class الأصلي.
• يدعم المبدأ المفتوح المغلق.
• يقلل من الحاجة إلى العديد من subclasses.
• يسمح بدمج السلوك ديناميكيًا.
• يحسن الفصل بين المسؤوليات.
• يعمل بشكل جيد مع interfaces وdependency injection.
• يساعد على عزل المخاوف الشاملة.
• يجعل ميزات مثل التسجيل والتخزين المؤقت قابلة لإعادة الاستخدام.

هذه الفوائد تجعل Decorator Pattern مفيدًا بشكل خاص في التطبيقات المتوسطة والكبيرة.

عيوب Decorator Pattern

يمكن أن يكون لـ Decorator Pattern أيضًا عيوب. قد يؤدي ذلك إلى إنشاء العديد من classes الصغيرة، مما قد يجعل التنقل في المشروع أكثر صعوبة إذا لم يتم تنظيم البنية بشكل جيد.

عيب آخر هو أن تصحيح الأخطاء يمكن أن يصبح أكثر صعوبة عندما يتم تغليف الكائن بعدة طبقات. قد يحتاج المطورون إلى التتبع من خلال عدة decorators لفهم السلوك الكامل.

يمكن أن يكون ترتيب Decorator مهمًا أيضًا. على سبيل المثال، قد يؤدي التسجيل قبل التخزين المؤقت إلى نتائج مختلفة عن التخزين المؤقت قبل التسجيل. يجب على المطورين توخي الحذر عند تكديس decorators.

متى يتم استخدام Decorator Pattern

استخدم Decorator Pattern عندما تحتاج إلى إضافة سلوك إلى الكائنات دون تعديل classes الأصلي.

يكون Decorator Pattern مفيدًا عندما:

• تريد إضافة التسجيل أو التخزين المؤقت أو التحقق من الصحة أو الترخيص حول الخدمة.
• تحتاج إلى الجمع بين سلوكيات اختيارية متعددة بشكل ديناميكي.
• تريد تجنب إنشاء العديد من ملفات subclasses.
• تريد الحفاظ على تركيز class الأصلي ونظيفه.
• أنت بحاجة إلى اتباع نفس interface أثناء إضافة سلوك إضافي.
• تريد فصل الاهتمامات الشاملة عن منطق العمل.

في حالة وجود هذه الشروط، يمكن أن يكون Decorator Pattern خيارًا قويًا للتصميم.

متى لا تستخدم Decorator Pattern

لا تستخدم Decorator Pattern عندما يكون السلوك بسيطًا ومن غير المرجح أن يتغير. إذا كانت إضافة ميزة مباشرة إلى class واضحة ولا تخرق حدود المسؤولية، فقد يكون decorator غير ضروري.

تجنب Decorator Pattern عندما:

• لا يحتاج الكائن إلى امتداد السلوك الديناميكي.
• يضيف النمط عددًا كبيرًا جدًا من classes بدون قيمة حقيقية.
• يمكن التعامل مع نفس السلوك ببساطة أكبر عن طريق التكوين.
• يصبح ترتيب decorators مربكًا.
• تنتمي الميزة بشكل طبيعي إلى class الأصلي.

Design patterns يجب أن يجعل الكود أكثر نظافة، وليس أكثر تعقيدًا.

الأخطاء الشائعة في Decorator Pattern

أحد الأخطاء الشائعة هو تغيير interface في decorator. يجب أن يحتفظ decorator عادةً بنفس interface مثل الكائن الذي يغلّفه حوله. إذا قام بتغيير interface، فقد يكون في الواقع يتصرف مثل adapter.

خطأ آخر هو وضع منطق العمل غير ذي صلة داخل decorators. يجب أن تضيف Decorators سلوكًا إضافيًا محددًا، ولا تصبح خدمة كبيرة classes.

الخطأ الثالث هو تكديس decorators دون التحكم في ترتيبها. يجب تشغيل بعض decorator قبل غيرها، ويجب أن يكون الترتيب واضحًا.

الخطأ الرابع هو إنشاء decorators لكل ميزة صغيرة. إذا كانت الميزة بسيطة وتنتمي إلى class، فقد لا يكون decorator ضروريًا.

أفضل الممارسات لـ Decorator Pattern

لاستخدام Decorator Pattern بشكل فعال، يجب على المطورين إبقاء decorator صغيرة ومركزة ومتسقة.

تتضمن أفضل الممارسات المفيدة ما يلي:

• استخدم interface واضحًا مشتركًا بين الكائن الأصلي وdecorators.
• اجعل كل decorator يركز على مسؤولية واحدة.
• استخدم dependency injection لالتفاف الخدمات بشكل نظيف.
• استخدم أسماء ذات معنى مثل CachedProductProvider أو LoggedPaymentGateway.
• احتفظ بأمر decorator واضحًا عند استخدام عدة decorator.
• تجنب تغيير interface العام في decorators.
• استخدم decorators للمسائل الشاملة مثل التسجيل والتخزين المؤقت والترخيص.
• لا تفرط في استخدام decorators للمشاكل البسيطة.

تساعد هذه الممارسات في الحفاظ على Decorator Pattern قابلاً للصيانة وعمليًا.

قائمة مرجعية عملية قبل استخدام Decorator Pattern

قبل استخدام Decorator Pattern، يمكن للمطورين طرح هذه الأسئلة:

• هل أحتاج إلى إضافة سلوك دون تغيير class الأصلي؟
• هل يمكن فصل السلوك الجديد إلى غلاف مركّز؟
• هل يجب أن يحتفظ الكائن المزخرف بنفس interface؟
• هل سيؤدي هذا إلى تجنب عدد كبير جدًا من subclasses؟
• هل سيؤدي هذا إلى جعل المخاوف الشاملة أكثر وضوحًا؟
• هل يمكن دمج decorators بأمان؟
• هل التعقيد الإضافي يستحق المرونة؟

إذا كانت الإجابة بنعم على العديد من هذه الأسئلة، فقد يكون Decorator Pattern اختيارًا جيدًا للتصميم.

الاستنتاج

Decorator Pattern عبارة عن نمط تصميم هيكلي يسمح للمطورين بإضافة سلوك إلى الكائنات ديناميكيًا دون تعديل classes الأصلي. إنه يعمل عن طريق تغليف كائن بكائن آخر يطبق نفس interface ويضيف وظائف إضافية.

يعد Decorator Pattern مفيدًا للتسجيل والتخزين المؤقت والتحقق من الصحة والترخيص ومنطق إعادة المحاولة والمراقبة والضغط والتشفير وغيرها من الاهتمامات الشاملة. وهو يدعم الكود النظيفة والتركيب وdependency injection والمبدأ المفتوح المغلق.

ومع ذلك، يجب استخدام Decorator بعناية. يمكن لعدد كبير جدًا من decorator أن يجعل تصحيح الأخطاء وتدفق الكائنات أكثر صعوبة في الفهم. عند تطبيقه بشكل صحيح، يعد Decorator Pattern أداة قوية لإنشاء برامج موجهة للكائنات مرنة وقابلة للصيانة وقابلة للتوسيع.