مبادئ البرمجة الشيئية

مرحبا هبر! اسمي فلاديسلاف رودين. أنا حاليًا رئيس دورة الهندسة الثقيلة في OTUS ، كما أقوم بتدريس دورات هندسة البرمجيات.



خاصة بالنسبة لبدء الفصول في الدفق الجديد من دورة "الهندسة المعمارية وأنماط التصميم" ، قمت بإعداد مادة أخرى للمؤلف.






المقدمة



عندما يتعلق الأمر بأنماط التصميم الكلاسيكية ، لا يسع المرء إلا أن يفكر في البرمجة الشيئية نفسها. بعد كل شيء ، أنماط GoF هي بالضبط أنماط برمجة موجهة للكائنات. البرمجة الوظيفية لها أنماطها الخاصة.



بشكل عام ، يتم ترتيب كل شيء على النحو التالي: هناك برمجة كائنية التوجه بحد ذاتها. لديه مبادئ. من مبادئ البرمجة الشيئية ، تتبع أنماط GRASP التي قمنا بتحليلها (كخيار - مبادئ SOLID) ، والتي بدورها تتبع أنماط GoF. يتبعها عدد من الأشياء المثيرة للاهتمام ، على سبيل المثال ، أنماط المؤسسة.



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



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



وبالتالي ، يتم تمثيل النظام كمجموعة من الكائنات في منطقة الموضوع ، والتي تتفاعل مع بعضها البعض بطريقة ما. كل كائن له ثلاثة مكونات: الهوية والحالة والسلوك.



حالة الكائن هي مجموعة من جميع حقوله وقيمها.



سلوك الكائن هو مجموعة من جميع طرق فئة الكائن.



هوية الكائن هي ما يميز كائن فئة عن كائن فئة آخر. من منظور Java ، يتم تعريف طريقة equals حسب الهوية.



مبادئ البرمجة الشيئية



البرمجة الشيئية لها عدد من المبادئ. فكرة عددهم تختلف. يدعي أحدهم أن هناك ثلاثة منهم (المدرسة القديمة للمبرمجين) ، شخص ما أن هناك أربعة منهم (مدرسة جديدة للمبرمجين):



  1. التجريد
  2. التغليف
  3. ميراث
  4. تعدد الأشكال


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



التغليف



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



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



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



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



ميراث



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

وطرق جديدة إذا لزم الأمر .



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



تعدد الأشكال



تعدد الأشكال هو القدرة على استخدام الفئات التابعة في سياق كان مخصصًا لفئة السلف.



يكمن وراء التعريف الأكثر سادية قدرة لغة البرمجة على تحليل مهمة ما وإعادة تشكيلها ومفاتيحها.






All Articles