يُعرَف نمط التصميم Design Pattern في هندسة البرمجيات بأنه حل عام قابل للتكرار لمشكلة متكررة الحدوث في تصميم البرمجيات. نمط التصميم ليس نموذجا نهائيا يمكن تحويله إلى تعليمات برمجية مباشرة؛ بل هو توصيف أو قالب لكيفية حل المشكلة، يمكن استخدامه في العديد من الحالات المختلفة.
استخدام أنماط التصميم
يمكن لأنماط التصميم أن تسرّع عملية التطوير عن طريق توفير تصوّرات Paradigms أثبتت جدواها بعد اختبارها مرات كثيرة. يتطلب التصميم البرمجي الفعال أن نأخذ بعين الاعتبار المشاكل التي قد لا تظهر إلا لاحقا عند التنفيذ. تساعد إعادة استخدام أنماط التصميم في منع الأمور الدقيقة من التسبب بمشاكل كبيرة، كما تحسّن من القدرة على قراءة التعليمات البرمجية للمبرمجين والمعماريين Architects الذين هم على دراية بهذه الأنماط.
يدرك الناس، في كثير من الأحيان، كيفية تطبيق تقنيات تصميم معينة لحل مشاكل بعينها فقط. لكن هذه التقنيات تكون صعبة التطبيق على نطاق أوسع من المشاكل. توفر أنماط التصميم حلولا عامة موثقة في تنسيق، لا يتطلب تفاصيل مرتبطة بمشكلة معينة. بالإضافة لذلك، تسمح هذه الأنماط للمطورين بالتواصل باستخدام أسماء معروفة ومفهومة جيدا للتفاعلات البرمجيّة software interactions. يمكن تحسين أنماط التصميم الشائعة مع مرور الوقت، الأمر الذي يجعلها أكثر قوة من التصاميم المخصصة.
أنماط التصميم الإنشائية Creational design patterns
تعنى نماذج التصميم هذه باستهلال الأصناف Class instantiation. يمكن تقسيم هذه النوعيّة من النماذج إلى فئتيْن: نماذج لإنشاء الأصناف ونماذج لإنشاء الكائنات. في حين تستخدم نماذج إنشاء الفئات التوريث Inheritance بفعالية في عملية التكوين، فإن نماذج إنشاء الكائنات تستخدم التفويض Delegation بفعالية لإنجاز العمل.
من أمثلة أنماط التصميم الإنشائية:
- نمط معمل التجريد Abstract Factory: يخلق عينة Instance لعدة عائلات من الأصناف.
- نمط الباني Builder: يقوم بفصل عملية بناء الكائن Object Construction عن عملية تمثيله Representation.
- نمط طريقة المعمل Factory Method: يخلق عينة لعدة أصناف مشتقة Derived classes.
أنماط التصميم الهيكلية Structural design patterns
تعنى أنماط التصميم هذه بتركيب Composition الكائنات والأصناف. تستخدم الأنماطُ الهيكليّة لإنشاء الأصناف التوريثَ Inheritance لتركيب واجهات Interfaces، أما الأنماطُ الهيكليّة لإنشاء الكائنات فتعرّف طرقا لتكوين الكائنات بهدف الحصول على وظائف جديدة.
من أمثلة هذه الأنماط:
- نمط المحول Adapter: يربط الواجهات Interfaces بأصناف مختلفة.
- نمط الجسر Bridge: يفصل واجهة الكائن عن تطبيقه Implementation.
- نمط المظهر Facade: صنف مفرد يمثل نظاما فرعيا Subsystem كاملا.
- نمط بيانات الصنف الخاصة Private Class Data: يقيد وصول المسترجعات Accessors والمعدّلات Mutators إلى خاصيّات الصنف.
أنماط التصميم السلوكية Behavioral design patterns
تعنى أنماط التصميم هذه بالتواصل Communication بين كائنات الأصناف. النماذج السلوكية هي تلك النماذج التي تهتم على وجه الخصوص بالتواصل بين الكائنات، ومن بينها:
- نمط سلسلة المسؤوليات Chain of Responsibility: طريقة لتمرير الطلب Request بين سلسلة من الكائنات.
- نمط السيطرة Command: يقوم بتغليف Encapsulate الطلب على هيئة كائن.
- نمط المفسّر Interpreter: طريقة لتضمين عناصر اللغة في البرنامج.
-
نمط المكرّر Iterator: يؤمن وصولا تسلسليا للعناصر في مجموعة ما.
نموذج الوسيط Mediator
النقد
انتقد بعض العاملين في مجال علوم الحاسب مفهوم أنماط التصميم وأبدوا اعتراضاتٍ عليه نجملها في ما يلي.
يستهدف المشكلة الخاطئة
تظهر الحاجة إلى الأنماط عند استخدام لغات البرمجة أو التقنيات التي لا تملك قدرة تجريد Abstraction كافية. في الحالة المثالية، لا ينبغي نسخ مفهوم ما بل تجدر الإشارة إليه. ولكن عند الإشارة إلى شيء ما بدل نسخه فلن يكون هناك نمط لتسميته أو الدلالة عليه، وهذا ما كتبه بول غراهام Paul Graham في مقال بعنوان “انتقام المهووسين Revenge of the Nerds “.
يقدم بيتر نورفيغ Peter Norvig نقاشا مشابها، حيث يوضح أن 16 نمطا من أصل 23 في كتاب أنماط التصميم (الذي يركز بشكل أساسي على ++C ) بُسِّطت أو ألغيت (عن طريق دعم اللغة المباشر لها) في كل من لغتي Lisp و Dylan.
يفتقر إلى الأسس الرسمية
لقد كانت دراسة أنماط التصميم متخصّصة جدا، وقد جادل البعض في الحاجة الملحة لوضع هذا المفهوم في إطار أكثر رسمية. في مؤتمر OOPSLA (البرمجة كائنيّة التوجّه: الأنظمة، اللغات والتطبيقات) عام 1999، خضعت عصابة الأربعة Gang of Four (بتعاونهم الكامل) إلى محاكمة علنية، اتهموا فيها بعدة جرائم تمس علوم الحاسب. وقد تمت إدانتهم من قبل ثلثي المحلفين الذين حضروا المحاكمة.
ملحوظة: غالبا ما يُشار إلى مؤلّفي كتاب Design Patterns: Elements of Reusable Object-Oriented Software (أنماط التصميم: مكوّنات من البرامج كائنيّة التوجّه القابلة لإعادة الاستخدام) الذي روّج لأنماط التصميم، غالبا ما يُشار إليهم باسم “عصابة الأربعة”.
يقود إلى حلول غير فعالة
إن فكرة نمط التصميم ما هي إلا محاولة لتقييس Standardize ما يعتبر سلفا مقبولا كأفضل ممارسة. قد يبدو هذا الأمر مفيدا من الجانب النظري، لكنه في الجانب العملي غالبا ما يؤدي إلى تكرار غير ضروري للتعليمات البرمجية. وبالتالي يكون الحل الأكثر فعالية هو استخدام تطبيق مصمم جيدا عوضا عن نمط تصميم بالكاد يعتبر جيدا.
لا يختلف كثيرا عن التجريدات الأخرى
يزعم بعض المؤلفين أن أنماط التصميم لا تختلف كثيرا عن أشكال التجريد الأخرى، وبأن استخدام مصطلح جديد (استعير من مجتمع العمارة) لوصف ظاهرة موجودة سابقا في مجال البرمجة يعتبر أمرا غير ضروري. تعدّ بنية بنية MVC ( “نموذج – عرض – متحكم”، “Model – View – Controller”) مثالا عن “نمط” يسبق مفهوم أنماط التصميم بعدة سنوات. ويجادل البعض بأن أول مساهمة في مجتمع أنماط التصميم (وكتاب عصابة الأربعة) هو استخدام كتاب A pattern language (لغة نمط) طريقةً للتوثيق Documentation؛ وهي ممارسة غالبا ما يتجاهلها المختصّون عند عرضهم لأصول مفهوم أنماط التصميم.
ترجمة - بتصرّف - لمقال Design Patterns لأصحابه Alexander Shvets, Gerhard Frey, Marina Pavlova.
حقوق الصورة البارزة محفوظة لـ Freepik
أفضل التعليقات
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.