التحليل والتصميم الموجه للكائنات

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

تُنجز عملية التحليل والتصميم الكائني التوجه (OOAD) في هندسة البرمجيات الحديثة غالبًا بطريقة تكرارية وتدريجية، حيث تُطور النماذج وتحسينها عبر مراحل متعددة. تنتج عن أنشطة تحليل كائني التوجه (OOA) نماذج تحليلية، بينما تُنتج أنشطة التصميم الكائني التوجه (OOD) نماذج تصميمية. يهدف هذا النهج إلى تطوير وتحسين هذه النماذج بشكل مستمر، مع الأخذ بعين الاعتبار عوامل رئيسية مثل تقليل المخاطر وتعظيم قيمة الأعمال.

تاريخ

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

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

في عام 1994، بدأ الأصدقاء الثلاثة لشركة Rational Software العمل معًا لتطوير لغة النمذجة الموحدة (UML). وفي وقت لاحق، وبالتعاون مع فيليب كروتشتن ووالكر رويس (الابن الأكبر لوينستون رويس)، قادوا مهمة ناجحة لدمج منهجياتهم الخاصة، OMT و OOSE وطريقة Booch، مع رؤى وخبرات مختلفة من قادة الصناعة الآخرين في Rational Unified Process (RUP)، وهي دليل شامل للعملية التكرارية والتدريجية وإطار عمل لتعلم أفضل ممارسات الصناعة لتطوير البرمجيات وإدارة المشاريع.[1] منذ ذلك الحين، أصبحت عائلة Unified Process هي على الأرجح المنهجية والنموذج المرجعي الأكثر شعبية للتحليل والتصميم الموجه نحو الكائنات.

ملخص

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

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

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

نموذج الشلال.
تُنجز عملية OOAD بطريقة تكرارية وتدريجية، وفقًا لما صيغ بواسطة العملية الموحدة.

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

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

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

يؤكد النموذج الموجه نحو الكائنات على الوحدات النمطية وإمكانية إعادة الاستخدام. الهدف من النهج الموجه نحو الكائنات هو تلبية مبدأ "الانفتاح  – الإغلاق". تكون الوحدة مفتوحة إذا كانت تدعم التمديد، أو إذا كانت الوحدة توفر طرقًا قياسية لإضافة سلوكيات جديدة أو وصف حالات جديدة. في النموذج الموجه للكائنات، يُحقق ذلك غالبًا عن طريق إنشاء فئة فرعية جديدة لفئة موجودة. تُغلق الوحدة إذا كانت لديها واجهة مستقرة محددة جيدًا يجب على جميع الوحدات الأخرى استخدامها والتي تحد من التفاعل والأخطاء المحتملة التي يمكن إدخالها في وحدة واحدة عن طريق التغييرات في وحدة أخرى. في النموذج الموجه نحو الكائنات، يُحقق ذلك من خلال تحديد الأساليب التي تستدعي الخدمات على الكائنات. يمكن أن تكون الأساليب عامة أو خاصة، أي أن بعض السلوكيات الفريدة للكائن لا تظهر لكائنات أخرى. يؤدي هذا إلى تقليل مصدر العديد من الأخطاء الشائعة في برمجة الكمبيوتر.[2]

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

التحليل الموجه نحو الكائنات

الغرض من أي نشاط تحليلي في دورة حياة البرنامج هو إنشاء نموذج للمتطلبات الوظيفية للنظام مستقلاً عن قيود التنفيذ.

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

النماذج الشائعة المستخدمة في OOA هي حالات الاستخدام ونماذج الكائنات. تصف حالات الاستخدام السيناريوهات الخاصة بوظائف المجال القياسية التي يجب على النظام إنجازها. تصف نماذج الكائنات أسماء وعلاقات الفئات (على سبيل المثال، الدائرة هي فئة فرعية من الشكل) والعمليات وخصائص الكائنات الرئيسية. يمكن أيضًا إنشاء نماذج أولية أو نماذج لواجهة المستخدم للمساعدة في الفهم.[4]

التصميم الموجه نحو الكائنات

التصميم الموجه نحو الكائنات (OOD) هو عملية تخطيط نظام من الكائنات المتفاعلة لحل مشكلة برمجية. إنها طريقة لتصميم البرمجيات. من خلال تحديد الفئات ووظائفها لأبنائها (الكائنات المولدة)، يمكن لكل كائن تشغيل نفس تنفيذ الفئة بحالتها.

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

تتضمن الموضوعات المهمة أثناء OOD أيضًا تصميم هياكل البرمجيات من خلال تطبيق الأنماط المعمارية وأنماط التصميم مع مبادئ التصميم الموجهة للكائنات.

المدخلات (المصادر) للتصميم الموجه للكائنات

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

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

المفاهيم الموجهة للكائنات

المفاهيم الخمسة الأساسية للتصميم الموجه للكائنات هي ميزات مستوى التنفيذ المضمنة في لغة البرمجة. غالبًا ما تُشار إلى هذه الميزات بالأسماء الشائعة التالية:

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

تصميم المفاهيم

  • تعريف الكائنات، إنشاء مخطط الفئة من المخطط المفاهيمي: عادة ما يُعين الكيان إلى الفئة.
  • تحديد السمات ونماذجها.
  • استخدم أنماط التصميم (إن وجدت): نمط التصميم ليس تصميمًا نهائيًا، بل هو وصف لحل مشكلة شائعة، في سياق ما.[6]

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

  • تحديد إطار عمل التطبيق (إن أمكن): إطار عمل التطبيق هو عادةً مجموعة من المكتبات أو الفئات التي تُستخدم لتنفيذ البنية القياسية للتطبيق لنظام تشغيل محدد. من خلال تجميع كمية كبيرة من التعليمات البرمجية القابلة لإعادة الاستخدام في إطار عمل، يوفر الكثير من الوقت للمطور حيث توفر مهمة إعادة كتابة كميات كبيرة من التعليمات البرمجية القياسية لكل تطبيق جديد يُطبق.
  • تحديد الكائنات/البيانات المستمرة (إن أمكن): حدد الكائنات التي يجب أن تستمر لفترة أطول من وقت تشغيل واحد للتطبيق. قم بتصميم تعيين علاقة الكائن إذا أُستخدمت قاعدة بيانات علائقية.
  • تحديد وتعريف الكائنات البعيدة (إن وجدت) وتنوعاتها.

مخرجات (مخرجات) التصميم الموجه نحو الكائنات

يُظهر مخطط التسلسل، كخطوط رأسية متوازية، عمليات أو أشياء مختلفة تعيش في وقت واحد، وكأسهم أفقية، الرسائل المتبادلة بينها، بالترتيب الذي تحدث به.
  • مخطط الفئة - مخطط الفئة هو نوع من مخططات UML ذات البنية الثابتة التي تصف بنية النظام من خلال إظهار فئات النظام وسماته والعلاقات بين الفئات. يمكن أن تكون الرسائل والفئات التي حُددت من خلال تطوير مخططات التسلسل بمثابة مدخلات للتوليد التلقائي لمخطط الفئة العالمية للنظام.

بعض مبادئ واستراتيجيات التصميم

  • حقن التبعية : الفكرة الأساسية هي أنه إذا كان الكائن يعتمد على وجود مثيل لكائن آخر، فسيحقن "حقن" الكائن المطلوب في الكائن التابع؛ على سبيل المثال، يمرر اتصال قاعدة بيانات كحجة إلى المنشئ بدلاً من إنشاء واحد داخليًا.
  • مبدأ التبعيات غير الدورية: يجب ألا يحتوي الرسم البياني للتبعيات الخاصة بالحزم أو المكونات (تعتمد الحبيبات على نطاق العمل لمطور واحد) على أي دورات. يُشار إلى هذا أيضًا باسم وجود رسم بياني غير دوري موجه.[7] على سبيل المثال، تعتمد الحزمة C على الحزمة B، والتي تعتمد بدورها على الحزمة A. إذا كانت الحزمة A تعتمد على الحزمة C، فسيكون لديك دورة.
  • مبدأ إعادة الاستخدام المركب: تفضيل التركيب المتعدد الأشكال للأشياء على الميراث.[8]

النمذجة الموجهة للكائنات

النمذجة الموجهة للكائنات (OOM) هي نهج شائع لنمذجة التطبيقات والأنظمة ومجالات الأعمال باستخدام النموذج الموجه للكائنات طوال دورات حياة التطوير بأكملها. OOM هي تقنية رئيسية تستخدم على نطاق واسع في أنشطة OOD وOOA في هندسة البرمجيات الحديثة.

ينقسم النمذجة الموجهة للكائنات عادةً إلى جانبين من العمل: نمذجة السلوكيات الديناميكية مثل العمليات التجارية وحالات الاستخدام، ونمذجة الهياكل الثابتة مثل الفئات والمكونات. OOA وOOD هما المستويان التجريديان المتميزان (أي مستوى التحليل ومستوى التصميم) أثناء OOM. لغة النمذجة الموحدة (UML) وSysML هما اللغتان القياسيتان الدوليتان الشائعتان المستخدمتان في النمذجة الموجهة للكائنات.[3]

فوائد OOM هي:

التواصل الفعال والناجح

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

تجريد مفيد ومستقر

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


 

مراجع

  1. ↑ "Rational Unified Process Best Practices for Software Development Teams" (PDF). Rational Software White Paper ع. TP026B. 1998. مؤرشف من الأصل (PDF) في 2021-04-21. اطلع عليه بتاريخ 2013-12-12.
  2. ↑ Meyer، Bertrand (1988). Object-Oriented Software Construction. Cambridge: Prentise Hall International Series in Computer Science. ص. 23. ISBN:0-13-629049-3.
  3. 1 2 Jacobsen، Ivar؛ Magnus Christerson؛ Patrik Jonsson؛ Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. ص. 15, 199. ISBN:0-201-54435-0.
  4. ↑ Jacobsen، Ivar؛ Magnus Christerson؛ Patrik Jonsson؛ Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. ص. 77–79. ISBN:0-201-54435-0.
  5. ↑ Conallen، Jim (2000). Building Web Applications with UML. Addison Wesley. ص. 147. ISBN:0201615770.
  6. ↑ إريك جاما؛ Richard Helm؛ Ralph Johnson؛ John Vlissides (2 يناير 1995). Design Patterns: Elements of Reusable Object-Oriented Software. أديسون ويسلي. ISBN:978-0-201-63361-0. مؤرشف من الأصل في 2025-02-17.
  7. ↑ "What Is Object-Oriented Design?". Object Mentor. مؤرشف من الأصل في 2007-06-30. اطلع عليه بتاريخ 2007-07-03.
  8. ↑ إريك جاما؛ Richard Helm؛ Ralph Johnson؛ John Vlissides (2 يناير 1995). Design Patterns: Elements of Reusable Object-Oriented Software. أديسون ويسلي. ISBN:978-0-201-63361-0. مؤرشف من الأصل في 2025-02-17.Erich Gamma؛ Richard Helm؛ Ralph Johnson؛ John Vlissides (January 2, 1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 978-0-201-63361-0.
هذه المقالة صادرة عن Wikipedia. النص متاح تحت رخصة المشاع الإبداعي - الإسناد - الترخيص بالمثل. قد تُطبَّق شروط إضافية على ملفات الوسائط.