الرئيسيةعريقبحث

نماذج التصميم (هندسة البرمجيات)


☰ جدول المحتويات


تعتبر نماذج التصميم (Design Patterns)‏ فرعاً مهمّاً من فروع وعلوم هندسة البرمجيات رغم انتقاد البعض له.[1][2][3] تهدف نماذج التصميم إلى الاستخدام المتكرر لحلول وضعت لمشاكل تعتبر في حد ذاتها متكررة أو موجودة بكثرة في عملية تصميم البرمجيات. لا تنطبق هذه النظرية على تصميم البرمجيات فحسب، بل تتعداه إلى عدة علوم أخرى مثل هندسة المباني وهندسة الإلكترونيات وحتّى الطبخ.

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

الفكرة من وراء نماذح البرمجة

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

تاريخ نماذج التصميم

ورد مصطلح نماذج (Patterns) أول مرة على لسان كريستوفر آلكسندر، وأوّل من أسقط المصطلح على هندسة البرمجيّات كان وارد كونينغهام.

في الحقيقة، لم تحظ نماذج التصميم بالشعبيّة إلاّ بعد نشر كتاب Design Patterns. Elements of reusable code سنة 1994. حدث في نفس السنة تنظيم أوّل مؤتمر مخصّص لمناقشة نماذج التصميم.

المكونات الرئيسية لقوالب التصميم

كريستوفر ألكسندر كتب عن قوالب التصميم: "كل قالب يصف مشكلة متكررة الحدوث، مع تقديم لفكرة علاج أو خوارزمية يمكن تطبيقها لملايين المرات دون أن تجد تشابه تام بين الحلول".

هناك أربع مكونات رئيسية لقوالب التصميم:

  1. الاسم : الاسم يختزل ذكر المشكلة وعلاجها والنتائج المترتبة على تطبيق القالب، لكن قد يكون أحيانا ايجاد اسم ملائم أكثر صعوبة من ايجاد حل للمشكلة. لتقريب الفكرة، تذكر عندما كنت مبتدءً في البرمجة وبدأت بعمل ادخال تعديلات على برنامج زميلك ثم فوجئت بالمتغير "س" أو "ص" أمامك،
  2. المشكلة : وصف للمشكلة ومتى تقوم بتطبيق القالب.
  3. الحل : شرح العناصر اللازمة للحل وكيفية ربطها وتعاونها. لا يقوم الحل بتقديم شرح تفصيلي لحل المشكلة وإنما يقوم بإعطاء حل تجريدي أو فكرة أولية للحل.
  4. النتائج والعواقب : النتائج المترتبة عند تطبيق القالب وهي الصوت الخفي من المكونات. تبحث بشكل عام استهلاك المكونات وتستخدم لتقويم القالب أونموذج التصميم.

أنماط نماذج التصميم

حسب GoF تصنف نماذج التصميم إلى 3 أنماط أو مجموعات:

  1. نماذج التصميم الإنشائية Creational Patterns
  2. نماذج التصميم السلوكية Behavioral Patterns
  3. نماذج تصميم هيكلية Structural Patterns

يتم من خلالها وصف استخدام مبادئ توزيع الصلاحيات (التفويض) والتجميع والاستشارة. لمزيد من المعلومات حول البرمجة غرضية التوجه راجع الترابط، الالتصاق، الوراثة، وتعددية الأِشكال. تصنيف آخر قدم ملاحظات حول نماذج تصميم بنيوية قد تطبق في المستوى البنيوي من التصميم مثال ذلك نمط نمط-عرض-متحكم.

نماذج إنشائية

الاسم الوصف في نماذج التصميم في مرحلة اكتمال الرماز المصدري[4] غير ذلك
Abstract factory يوفر واجهة لإنشاء عائلات من أغراض مستقلة أو مرتبطة مع بعضها من دون التصريح عن الصف الذي تم استخدامه. نعم نعم لا يوجد
Builder يفصل عملية بناء غرض مركب عن عملية تمثيل هذا الغرض ويسمح لعملية البناء الواحدة بأن تعطي أكثر من تمثيل. نعم لا لا يوجد
Factory method يوفر واجهة لإنشاء غرض وحيد تقوم الصفوف الفرعية في اختيار من اي صف سينشأ هذا الغرض. نعم نعم لا يوجد
Lazy initialization يتم فيه تأجيل إنشاء الغرض أو القيام بحساب ما أو عملية ما إلى وقت لاحق بحيث تكون تكلفة هذه العملية كبيرة لذا يتم تأجيلها إلى ان يصبح هناك حاجة لها. نعم لا [5] PoEAA
Multiton pattern يضمن أن هناك غرض واحد فقط تم انشاؤه من الصف الهدف ويضمن تمكن كل الصفوف الأخرى من الوصول إلى هذا الغرض دون الحاجة لإنشاء غرض جديد. لا لا لا يوجد
Object pool pattern يساعد في تجنب حجز وتحرير الموارد المكلف عن طريق تدوير الأغراض التي لم يعد هناك حاجة لاستخدامها. لا لا لا يوجد
Prototype pattern يصنع غرض واحد فقط من الصف وعند الحاجة لأغراض أخرى فيتم نسخ الغرض الذي تم انشاؤوه في المرة الأولى نعم لا لا يوجد
Resource Acquisition Is Initialization يضمن أن الموارد المحجوزة قد تم تحريرها عن طريق ربط هذه الموارد مع دورة حياة الغرض لا لا لا يوجد
Singleton pattern يضمن أن الصف قد تم إنشاء غرض واحد منه فقط ويؤمن وصول عام من قبل كل الأغراض الباقية إلى هذا الغرض نعم نعم لا يوجد

نماذج التصميم الهيكلية

الاسم الوصف في نماذج التصميم في مرحلة اكتمال الرماز المصدري[4] غير ذلك
نموذج التصميم المحول يحول واجهة صف معين من شكل إلى اخر بحيث يمكن لواجهة اخرى التعامل معها. نعم نعم لا يوجد
Bridge يقوم بفصل التجريد عن التنفيذ بشكل يسمع للاثنين بالاختلاف بشكل مستقل. نعم نعم لا يوجد
نموذج التصميم المجمع يركب الاغراض بشكل شجرة بحيث كل ترث الاغراض من بعضها فيسمح للزبون بالتعامل مع غرض واحد (الشجرة) مؤلف من عدة أغراض نعم نعم لا يوجد
Decorator يضيف فعالية جديدة لغرض معين بشكل ديناميكي اثناء التنفيذ، اي دون تعديل الغرض الاساسي. ويبقي على الواجهة الخاصة بهذا الغرض كما هي. نعم نعم لا يوجد
Extension object يضيف فعالية إلى الوراثة من دون تعديل هذه الوراثة لا لا تطوير البرمجيات السريع (اجايل)
Facade يوفر واجهة موحدة لمجموعة واجهات في نظام فرعي ويؤمن واجهة من مستوى اعلى تجعل التعامل مع النظام الفرعي أسهل. نعم نعم لا يوجد
Flyweight يستخدم المشاركة لدعم عدد كبير من الاغراض المتشابهة بشكل فعال. نعم لا لا يوجد
Front controller هذا النموذج خاص بتصميم تطبيقات الويب. يوفر نقطة ولوج مركزية للتعامل مع الطلبات. لا نعم غير موجود
Marker هو عبارة عن واجهة فارغة تربط المعلومات مع الصف. لا لا جوشوا بلوخ
Module يجمع عدة عناصر مرتبطة كالصفوف، والصفوف المفردة، والطرق، والتي تستخدم بشكل واسع عن طريق نقطة ولوج واحدة مبدئية. لا لا لا يوجد
Proxy يوفر مكان فارغ محجوز لغرض اخر ليتحكم بالوصول إليه. نعم لا لا يوجد
Twin[6] يسمح بالوراثة المتعدة في لغات البرمجة التي لا تسمح بذلك. لا لا لا يوجد

نماذج التصميم السلوكية

الاسم الوصف في نماذج التصميم في مرحلة اكتمال الرماز المصدري غير ذلك
Blackboard نمط للذكاء الصناعي لتجميع عدة مصادر للمعلومات معاً. لا لا لا يوجد
Chain of responsibility يتم فيه تجنب التصاق مرسل الطلب مع مستقبل الطلب عن طريق اعطاء الفرصة لأكثر من غرض لاستقبال الطلب من المرسل بحيث اذا كان الغرض المستقبل غير قادر على تنفيذ الطلب يقوم بتمريره لغرض مستقبل اخر وهكذا حتى يتم الوصول إلى غرض قادر على تنفيذ الطلب وإعادة النتيجة للمرسل نعم لا لا يوجد
Command يقوم بتغليف الطلب على شكل غرض مما يسمح بتمرير عدة طلبات زبائن معاً ويسمح باستخدام الارتال وتسجيل الطلبات ويدعم الطلبات غير القابلة للتنفيذ. نعم لا لا يوجد
Interpreter في لغة معينة، يتم تعريف تمثيل القواعد الخاصة بهذه اللغة بالإضافة إلى مفسر يستخدم هذا التمثلي لتفسير جمل هذه اللغة نعم لا لا يوجد
Iterator يوفر طريقة للمرور على عناصر غرض مركب بشكل تسلسلي دون كشف طريقة تمثيل العناصر في هذا الغرض نعم نعم لا يوحد
Mediator يعرف غرض يقوم بتحديد طريقة تفاعل عدة أغراض مع بعضها البعض، يخفف هذا النمط من الالتصاق لأنه ينمع الأغراض من الدلالة على بعضها بشكل مباشر، وبدلاً من ذلك فهي تتصل مع بعضها عن طريق غرض وسيط وبالتالي يتم السماح لفعالية هذه الأغراض بالاختلاف دون القلق من تأثر الأغراض الأخرى بهذا الاختلاف نعم لا لا يوجد
Memento يقوم بأخذ صورة عن الحالة الحالية لغرض ما مما يسمح لهذا الغرض بالعودة إلى هذه الحالة متى دعت الحاجة. نعم لا لا يوجد
Null object يتم إنشاء غرض افتراضي ليحل محل اي مرجعية لغرض غير موجود. لا لا لا يوجد
المراقب (نموذج تصميم) يعرف ارتباط من نوع واحد-متعدد بين أغراض بحيث إن تغيرت حالة غرض معين يتم إرسال تنبيه بذلك التغيير إلى باقي الإغراض بشكل تلقائي. نعم نعم لا يوجد
Servant يعرف فعالية مشتركة لمجموعة صفوف لا لا لا يوجد
Specification يعيد تجميع منطق العمل بشكل بولياني لا لا لا يوجد
State يسمح للغرض بتعديل سلوكه تبعاً لحالته الداخلية نعم لا لا يوجد
نموذج الإستراتيجية يتم تعريف مجموعة من الخوارزميات ويتم تغليف كل واحدة منها، ويتم التبديل بين هذه الخوارزميات حسب الحاجة بحيث يتم استخدام الخوارزمية المناسبة بشكل مستقل عن الزبون. نعم نعم لا يوحد
Template method يتم تعريف هيكل الخوارزمية ضمن العملية ويتم تحويل بعض خطوات التنفيذ إلى صفوف فرعية. يسمح هذا النمط للصفوف الفرعية بتعديل خطوات معينة في الخوارزمية دون تعديل البنية الأساسية للخوارزمية. نعم نعم لا يوحد
Visitor يتم تعيين عملية ليتم تنفيذها على عناصر بنية غرض. هذا النمط يسمح بتعريف عمليات جديدة دون تغيير عناصر الغرض الذي يتم تطبيق هذه العمليات عليه نعم لا لا يوجد

نماذج التصميم المتزامنة

الاسم الوصف في POSA2 غير ذلك
Active object (الغرض الفعال) يفصل تنفيذ الدالة عن استدعائها والذي يكون في مسلك تحكم خاص به. الهدف من هذه العملية هو انشاء تزامن عن طريق استخدام استدعاء دوال غير متزامن ومجدول للتعامل مع الطلبات. نعم لا يوجد
Balking يقوم بتنفيذ أمر ما على الغرض فقط في حال كان هذا الغرض في حالة معينة محددة. لا لا يوحد
Binding properties يجمع عدة مراقبين بهدف إجبار خاصيات ضمن أغراض مختلفة على التزامن والتنسيق فيما بينها بطريقة ما. لا لا يوجد
سلسلة الكتل طريقة غير مركزية لتخزين البيانات والموافقة على طرق معالجتها في شجرة ميركل، ويستخدم (اختيارياً) التوقيع الرقمي لأي مشاركة. لا لا يوجد
Double-checked locking يخفف الجهد المبذول للحصول على قفل عن طريق اختبار منقطة القفل أولاً بطريقة غير آمنة، في حال نجح الاختبار يتم الاستمرار بتنفيذ عملية القفل. يمكن أن يكون غير آمن عند التنفيذ في بعض تركيبات لغات البرمجة/العتاد الصلب، وبالتالي يعتبر أحياناً كأنه نموذج مضاد نعم لا يوحد
Event-based asynchronous (عدم التزامن المبني على الاحداث) يعنون المشكلة باستخدام نموذج غير متزامن يقع ضمن برامج متعددة المسالك لا لا يوجد
Guarded suspension (تعليق الحراسة) يدير عمليات التي تتطلب قفل وشروط مسبقة محققة قبل البدء بتنفيذها. لا لا يوجد
Join (المشاركة) يوفر هذا النمط طريقة لكتابة برامج متزامنة ومتوازية وموزعة عن طريق تبادل الرسائل. مقارنةً باستخدام المسالك والأقفال، يكون هذا النمط ذو مستوى أعلى برمجياً. لا لا يوجد
قفل (حوسبة) (القفل) يقوم أحد المسالك بوضع قفل على مورد ما فيمنع باقي المسالك من الوصول إليه وتعديله. لا [7]PoEAA
صيغة التراسل (نموذج التراسل) يسمح بتبادل المعلومات (مثلاً الرسائل) بين عناصر التطبيق. لا لا يوجد
Monitor object هو غرض تكون دواله عرضة للاستبعاد المشترك وبالتالي يمنع أغراض متعددة من محاولة استخدامه في نفس الوقت. نعم لا يوجد
Reactor غرض رد الفعل يوفر واجهة غير متزامنة للموارد التي يجب أن يتم التعامل معها بشكل متزامن. نعم لا يوجد
Read-write lock نموذج اقرأ-اكتب-اقفل يسمح بالوصول وقراءة غرض بنفس الوقت من قبل عدة أطراف لكن يتطلب، رغم ذلك، وصول حصري مفرد عند القيام بعملية كتابة. لا لا يوجد
جدولة (حاسوب) يتولى التحكم عند قيام المسالك بتنفيذ كود مخصص لمسلك مفرد. لا لا يوجد
مؤشرات الترابط حوض المسالك هو نموذج يحوي عدة مسالك يتم انشاؤها لتنفيذ عدة مهام يتم عادة ترتيبهاا في رتل. عادةً يكون عدد المهام أكبر من عدد المسالك. يمكن اعتباره حالة خاصة من نموذج حوض الأغراض object pool لا لا يوجد
Thread-Specific Storage (التخزين الخاص بالمسلك) يتم فيه تخصيص جزء من الذاكرة بشكل ثابت أو عام من أجل مسلك معين. نعم لا يوجد

مراجع

  1. Smith, Reid (October 1987). Panel on design methodology. OOPSLA '87 Addendum to the Proceedings. doi:10.1145/62138.62151.
  2. Graham, Paul (2002). Revenge of the Nerds. مؤرشف من الأصل في 07 يونيو 201911 أغسطس 2012.
  3. [1] - تصفح: نسخة محفوظة 03 مارس 2016 على موقع واي باك مشين.
  4. Steve,, McConnell,. Code complete.  . OCLC 54974573. مؤرشف من الأصل في 15 ديسمبر 2019.
  5. "Martin Fowler: books". martinfowler.com. مؤرشف من الأصل في 4 يوليو 201210 فبراير 2017.
  6. ( كتاب إلكتروني PDF ) https://web.archive.org/web/20170829171120/http://ssw.jku.at/Research/Papers/Moe99/Paper.pdf. مؤرشف من الأصل ( كتاب إلكتروني PDF ) في 29 أغسطس 2017.
  7. "Martin Fowler: books". martinfowler.com. مؤرشف من الأصل في 4 يوليو 201211 فبراير 2017.

موسوعات ذات صلة :