نماذج التصميم (هندسة البرمجيات)
نماذج التصميم
| صنف فرعي من | |
|---|---|
| جانب من جوانب |
تعتبر نماذج التصميم (بالإنجليزية: Design Patterns) فرعاً مهمّاً من فروع وعلوم هندسة البرمجيات رغم انتقاد البعض له.[1][2][3] تهدف نماذج التصميم إلى الاستخدام المتكرر لحلول وضعت لمشاكل تعتبر في حد ذاتها متكررة أو موجودة بكثرة في عملية تصميم البرمجيات. لا تنطبق هذه النظرية على تصميم البرمجيات فحسب، بل تتعداه إلى عدة علوم أخرى مثل هندسة المباني وهندسة الإلكترونيات وحتّى الطبخ.
من الأخطاء المنتشرة اعتبار نماذج التصميم حلولًا كاملة أو جاهزة للاستخدام مباشرة، فهي لا تغدو أن تكون إلا نموذجا كما يدل اسمها يحتاج للتكييف والتحديد أكثر لكي يواجه مشكلة محددة. أغلب نماذج التصميم تعتمد على التوجه الكائني في البرمجة. لذلك نجدها تضع تصوراً قائم على التفاعلات والعلاقات الممكنة بين مختلف الفئات المكونة للبرنامج.
الفكرة من وراء نماذج البرمجة[عدل]
لنقرب الفكرة إلى ذهن القارئ، علينا أن نربط الموضوع بمثال حي من الحياة اليومية. تخيل أنك تقود سيارتك في مكان منعزل ولأول مرة وفجأة اختلت سيطرتك على السيارة بسبب وجود عطل في الإطار. لأول مرة في حياتك تجد أنك بحاجة إلى تغيير الإطار مع أنك لم تعمل ذلك من قبل. سوف تبدأ بالتفكير بجميع الحلول المتاحة أمامك. عادة ما كنت ترى الناس يقومون برفع السيارة فتفعل نفس الشيء، ثم انك بحاجة إلى فصل البراغي انها مشدودة بشكل قوي وأنا لا أستطيع السيطرة على العجل لأنه في الهواء وكلما أحاول دار العجل، إذا علي أن انزل السيارة أولا وأفصل البراغي والسيارة على الأرض... وهكذا. تعلمك من هذا الدرس يجعل خطوات إصلاح العجلة اسرع وما برمجة الحاسوب ببعيد عن هذا المثال. دائما ما نواجه مشاكل في البرمجة سبق وأن تعرضنا لها مرارا فنحاول تطبيق الحلول السابقة عليها واعادة استخدام هذه الاساليب مع إعادة تعديلها بما يتوافق والمشكلة الراهنة...
تاريخ نماذج التصميم[عدل]
ورد مصطلح نماذج (Patterns) أول مرة على لسان كريستوفر آلكسندر، وأوّل من أسقط المصطلح على هندسة البرمجيّات كان وارد كونينغهام.
في الحقيقة، لم تحظ نماذج التصميم بالشعبيّة إلاّ بعد نشر كتاب Design Patterns. Elements of reusable code سنة 1994. حدث في نفس السنة تنظيم أوّل مؤتمر مخصّص لمناقشة نماذج التصميم.
المكونات الرئيسية لقوالب التصميم[عدل]
كريستوفر ألكسندر كتب عن قوالب التصميم: «كل قالب يصف مشكلة متكررة الحدوث، مع تقديم لفكرة علاج أو خوارزمية يمكن تطبيقها لملايين المرات دون أن تجد تشابه تام بين الحلول».
هناك أربع مكونات رئيسية لقوالب التصميم:
- الاسم: الاسم يختزل ذكر المشكلة وعلاجها والنتائج المترتبة على تطبيق القالب، لكن قد يكون أحيانا ايجاد اسم ملائم أكثر صعوبة من ايجاد حل للمشكلة. لتقريب الفكرة، تذكر عندما كنت مبتدءً في البرمجة وبدأت بعمل ادخال تعديلات على برنامج زميلك ثم فوجئت بالمتغير «س» أو «ص» أمامك،
- المشكلة: وصف للمشكلة ومتى تقوم بتطبيق القالب.
- الحل: شرح العناصر اللازمة للحل وكيفية ربطها وتعاونها. لا يقوم الحل بتقديم شرح تفصيلي لحل المشكلة وإنما يقوم بإعطاء حل تجريدي أو فكرة أولية للحل.
- النتائج والعواقب: النتائج المترتبة عند تطبيق القالب وهي الصوت الخفي من المكونات. تبحث بشكل عام استهلاك المكونات وتستخدم لتقويم القالب أونموذج التصميم.
أنماط نماذج التصميم[عدل]
حسب GoF تصنف نماذج التصميم إلى 3 أنماط أو مجموعات:
- نماذج التصميم الإنشائية Creational Patterns
- نماذج التصميم السلوكية Behavioral Patterns
- نماذج تصميم هيكلية Structural Patterns
يتم من خلالها وصف استخدام مبادئ توزيع الصلاحيات (التفويض) والتجميع والاستشارة. لمزيد من المعلومات حول البرمجة غرضية التوجه راجع الترابط، الالتصاق، الوراثة، وتعددية الأِشكال. تصنيف آخر قدم ملاحظات حول نماذج تصميم بنيوية قد تطبق في المستوى البنيوي من التصميم مثال ذلك نمط نمط-عرض-متحكم.
نماذج إنشائية[عدل]
| الاسم | الوصف | في نماذج التصميم | في مرحلة اكتمال الرماز المصدري[4] | غير ذلك |
|---|---|---|---|---|
| Abstract factory | يوفر واجهة لإنشاء عائلات من أغراض مستقلة أو مرتبطة مع بعضها من دون التصريح عن الصف الذي تم استخدامه. | نعم | نعم | لا يوجد |
| نمط تصميم الباني | يفصل عملية بناء غرض مركب عن عملية تمثيل هذا الغرض ويسمح لعملية البناء الواحدة بأن تعطي أكثر من تمثيل. | نعم | لا | لا يوجد |
| نمط طريقة المصنع | يوفر واجهة لإنشاء غرض وحيد تقوم الصفوف الفرعية في اختيار من اي صف سينشأ هذا الغرض. | نعم | نعم | لا يوجد |
| Lazy initialization | يتم فيه تأجيل إنشاء الغرض أو القيام بحساب ما أو عملية ما إلى وقت لاحق بحيث تكون تكلفة هذه العملية كبيرة لذا يتم تأجيلها إلى ان يصبح هناك حاجة لها. | نعم | لا | [5] PoEAA |
| Multiton pattern | يضمن أن هناك غرض واحد فقط تم انشاؤه من الصف الهدف ويضمن تمكن كل الصفوف الأخرى من الوصول إلى هذا الغرض دون الحاجة لإنشاء غرض جديد. | لا | لا | لا يوجد |
| Object pool pattern | يساعد في تجنب حجز وتحرير الموارد المكلف عن طريق تدوير الأغراض التي لم يعد هناك حاجة لاستخدامها. | لا | لا | لا يوجد |
| Prototype pattern | يصنع غرض واحد فقط من الصف وعند الحاجة لأغراض أخرى فيتم نسخ الغرض الذي تم انشاؤوه في المرة الأولى | نعم | لا | لا يوجد |
| اكتساب الموارد تهيئة | يضمن أن الموارد المحجوزة قد تم تحريرها عن طريق ربط هذه الموارد مع دورة حياة الغرض | لا | لا | لا يوجد |
| النمط المفرد | يضمن أن الصف قد تم إنشاء غرض واحد منه فقط ويؤمن وصول عام من قبل كل الأغراض الباقية إلى هذا الغرض | نعم | نعم | لا يوجد |
نماذج التصميم الهيكلية[عدل]
| الاسم | الوصف | في نماذج التصميم | في مرحلة اكتمال الرماز المصدري[4] | غير ذلك |
|---|---|---|---|---|
| نموذج التصميم المحول | يحول واجهة صف معين من شكل إلى اخر بحيث يمكن لواجهة اخرى التعامل معها. | نعم | نعم | لا يوجد |
| نموذج التصميم جسر | يقوم بفصل التجريد عن التنفيذ بشكل يسمع للاثنين بالاختلاف بشكل مستقل. | نعم | نعم | لا يوجد |
| نموذج التصميم المجمع | يركب الاغراض بشكل شجرة بحيث كل ترث الاغراض من بعضها فيسمح للزبون بالتعامل مع غرض واحد (الشجرة) مؤلف من عدة أغراض | نعم | نعم | لا يوجد |
| نموذج التصميم ديكور | يضيف فعالية جديدة لغرض معين بشكل ديناميكي اثناء التنفيذ، اي دون تعديل الغرض الاساسي. ويبقي على الواجهة الخاصة بهذا الغرض كما هي. | نعم | نعم | لا يوجد |
| Extension object | يضيف فعالية إلى الوراثة من دون تعديل هذه الوراثة | لا | لا | تطوير البرمجيات السريع (اجايل) |
| Facade | يوفر واجهة موحدة لمجموعة واجهات في نظام فرعي ويؤمن واجهة من مستوى اعلى تجعل التعامل مع النظام الفرعي أسهل. | نعم | نعم | لا يوجد |
| نموذج التصميم وزن الذبابة | يستخدم المشاركة لدعم عدد كبير من الاغراض المتشابهة بشكل فعال. | نعم | لا | لا يوجد |
| Front controller | هذا النموذج خاص بتصميم تطبيقات الويب. يوفر نقطة ولوج مركزية للتعامل مع الطلبات. | لا | نعم | غير موجود |
| Marker | هو عبارة عن واجهة فارغة تربط المعلومات مع الصف. | لا | لا | جوشوا بلوخ |
| Module | يجمع عدة عناصر مرتبطة كالصفوف، والصفوف المفردة، والطرق، والتي تستخدم بشكل واسع عن طريق نقطة ولوج واحدة مبدئية. | لا | لا | لا يوجد |
| نمط الوكيل | يوفر مكان فارغ محجوز لغرض اخر ليتحكم بالوصول إليه. | نعم | لا | لا يوجد |
| Twin[6] | يسمح بالوراثة المتعدة في لغات البرمجة التي لا تسمح بذلك. | لا | لا | لا يوجد |
نماذج التصميم السلوكية[عدل]
| الاسم | الوصف | في نماذج التصميم | في مرحلة اكتمال الرماز المصدري | غير ذلك |
|---|---|---|---|---|
| Blackboard | نمط للذكاء الصناعي لتجميع عدة مصادر للمعلومات معاً. | لا | لا | لا يوجد |
| نمط سلسلة المسؤولية | يتم فيه تجنب التصاق مرسل الطلب مع مستقبل الطلب عن طريق اعطاء الفرصة لأكثر من غرض لاستقبال الطلب من المرسل بحيث اذا كان الغرض المستقبل غير قادر على تنفيذ الطلب يقوم بتمريره لغرض مستقبل اخر وهكذا حتى يتم الوصول إلى غرض قادر على تنفيذ الطلب وإعادة النتيجة للمرسل | نعم | لا | لا يوجد |
| Command | يقوم بتغليف الطلب على شكل غرض مما يسمح بتمرير عدة طلبات زبائن معاً ويسمح باستخدام الارتال وتسجيل الطلبات ويدعم الطلبات غير القابلة للتنفيذ. | نعم | لا | لا يوجد |
| Interpreter | في لغة معينة، يتم تعريف تمثيل القواعد الخاصة بهذه اللغة بالإضافة إلى مفسر يستخدم هذا التمثلي لتفسير جمل هذه اللغة | نعم | لا | لا يوجد |
| نمط المكرر | يوفر طريقة للمرور على عناصر غرض مركب بشكل تسلسلي دون كشف طريقة تمثيل العناصر في هذا الغرض | نعم | نعم | لا يوحد |
| 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 (التخزين الخاص بالمسلك) | يتم فيه تخصيص جزء من الذاكرة بشكل ثابت أو عام من أجل مسلك معين. | نعم | لا يوجد |
مراجع[عدل]
- ^ Smith، Reid (أكتوبر 1987). "Panel on design methodology". OOPSLA '87 Addendum to the Proceedings. DOI:10.1145/62138.62151.
- ^ Graham، Paul (2002). Revenge of the Nerds. مؤرشف من الأصل في 2019-06-07. اطلع عليه بتاريخ 2012-08-11.
- ^ [1] نسخة محفوظة 03 مارس 2016 على موقع واي باك مشين.
- ^ أ ب Steve,، McConnell,. Code complete. ISBN:9780735619678. OCLC:54974573. مؤرشف من الأصل في 2019-12-15.
{{استشهاد بكتاب}}:|archive-date=/|archive-url=timestamp mismatch (مساعدة)صيانة الاستشهاد: أسماء متعددة: قائمة المؤلفين (link) صيانة الاستشهاد: علامات ترقيم زائدة (link) - ^ "Martin Fowler: books". martinfowler.com. مؤرشف من الأصل في 2012-07-04. اطلع عليه بتاريخ 2017-02-10.
- ^ (PDF) https://web.archive.org/web/20170829171120/http://ssw.jku.at/Research/Papers/Moe99/Paper.pdf. مؤرشف من الأصل (PDF) في 2017-08-29.
{{استشهاد ويب}}: الوسيط|title=غير موجود أو فارغ (مساعدة) - ^ "Martin Fowler: books". martinfowler.com. مؤرشف من الأصل في 2012-07-04. اطلع عليه بتاريخ 2017-02-11.
| نماذج التصميم في المشاريع الشقيقة: | |
| |
