كيفية شرح مفاهيم البرمجة الشيئية لطفل عمره 6 سنوات

هل لاحظت كيف يتم دائمًا طرح الأسئلة المبتذلة نفسها في مقابلات العمل - مرارًا وتكرارًا؟

أنا متأكد من أنك تعرف ما أعنيه.

فمثلا:

أين ترى نفسك بعد خمس سنوات؟

أو حتى أسوأ:

ما الذي تعتبره أكبر نقاط ضعفك؟

آه ... أعطني استراحة. أنا أعتبر الإجابة على هذا السؤال نقطة ضعف كبيرة! على أي حال ، ليس وجهة نظري.

بقدر ما قد تكون أسئلة مثل هذه تافهة ، إلا أنها مهمة لأنها تقدم أدلة عنك. حالتك الذهنية الحالية ، موقفك ، وجهة نظرك.

عند الإجابة ، يجب أن تكون حذرًا ، فقد تكشف شيئًا تندم عليه لاحقًا.

اليوم أريد أن أتحدث عن نوع مماثل من الأسئلة في عالم البرمجة:

ما هي المبادئ الأساسية للبرمجة الشيئية؟

لقد كنت على جانبي هذا السؤال. إنه أحد تلك الموضوعات التي يتم طرحها كثيرًا بحيث لا يمكنك السماح لنفسك بعدم معرفتها.

عادة ما يتعين على المطورين المبتدئين والمبتدئين الإجابة عليها. لأنها طريقة سهلة للمحاور لإخبار ثلاثة أشياء:

  1. هل استعد المرشح لهذه المقابلة؟

    نقاط المكافأة إذا سمعت إجابة على الفور - فهذا يدل على نهج جاد.

  2. هل تجاوز المرشح مرحلة البرنامج التعليمي؟

    يوضح فهم مبادئ البرمجة الشيئية (OOP) أنك تجاوزت النسخ واللصق من البرامج التعليمية - فأنت ترى الأشياء بالفعل من منظور أعلى.

  3. هل فهم المرشح عميق أم ضحل؟

    غالبًا ما يساوي مستوى الكفاءة في هذا السؤال مستوى الكفاءة في معظم الموضوعات الأخرى . صدقني.

المبادئ الأربعة للبرمجة الشيئية هي التغليف ، التجريد ، الوراثة ،و تعدد الأشكال .

قد تبدو هذه الكلمات مخيفة لمطور مبتدئ. وفي بعض الأحيان تضاعف التفسيرات المعقدة والمطولة بشكل مفرط في ويكيبيديا من الالتباس.

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

التغليف

لنفترض أن لدينا برنامجًا. يحتوي على عدد قليل من الكائنات المختلفة منطقيًا والتي تتواصل مع بعضها البعض - وفقًا للقواعد المحددة في البرنامج.

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

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

لنفترض أننا نبني لعبة Sims صغيرة. هناك أناس وهناك قطة. يتواصلون مع بعضهم البعض. نريد تطبيق التغليف ، لذلك نقوم بتغليف منطق "cat" في ملفCatصف دراسي. قد يبدو مثل هذا:

هنا "حالة" القط هي المتغيرات الخاصةmood ، hungryو energy. كما أن لديها طريقة خاصة meow(). يمكن أن تسميها متى شئت ، لا تستطيع الفصول الأخرى إخبار القطة متى تريد مواء.

يتم تعريف ما يمكنهم فعله في الأساليب العامةsleep() ، play()و feed(). كل واحد منهم يعدل الحالة الداخلية بطريقة ما وقد يستدعي meow(). وهكذا ، يتم الربط بين الدولة الخاصة والأساليب العامة.

هذا تغليف.

التجريد

يمكن اعتبار التجريد امتدادًا طبيعيًا للتغليف.

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

التجريد هو مفهوم يهدف إلى تخفيف هذه المشكلة.

يعني تطبيق التجريد أن كل كائن يجب أن يعرض فقط آلية عالية المستوى لاستخدامه.

يجب أن تخفي هذه الآلية تفاصيل التنفيذ الداخلية. يجب أن تكشف فقط عن العمليات ذات الصلة بالكائنات الأخرى.

فكر - آلة صنع القهوة. إنه يفعل الكثير من الأشياء ويصدر ضوضاء ملتوية تحت الغطاء. ولكن كل ما عليك فعله هو وضع القهوة والضغط على زر.

ويفضل أن تكون هذه الآلية سهلة الاستخدام ونادراً ما تتغير بمرور الوقت. فكر في الأمر على أنه مجموعة صغيرة من الأساليب العامة التي يمكن لأي فصل دراسي آخر الاتصال بها دون "معرفة" كيفية عملها.

مثال آخر من الحياة الواقعية على التجريد؟

فكر في كيفية استخدامك لهاتفك:

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

نادرًا ما تؤثر تغييرات التنفيذ - على سبيل المثال ، تحديث البرنامج - على التجريد الذي تستخدمه.

ميراث

حسنًا ، لقد رأينا كيف يمكن للتغليف والتجريد مساعدتنا في تطوير والحفاظ على قاعدة بيانات كبيرة.

ولكن هل تعرف ما هي المشكلة الشائعة الأخرى في تصميم OOP؟

غالبًا ما تكون الكائنات متشابهة جدًا. يتشاركون في منطق مشترك. لكنهما ليسا متماثلين تمامًا . قرف…

إذن كيف نعيد استخدام المنطق المشترك ونستخرج المنطق الفريد في فئة منفصلة؟ طريقة واحدة لتحقيق هذا هو الميراث.

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

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

فمثلا:

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

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

تعدد الأشكال

نحن ننتقل إلى أكثر الكلمات تعقيدًا! تعدد الأشكال يعني "العديد من الأشكال" في اليونانية.

لذلك نحن نعرف بالفعل قوة الميراث ونستخدمها بسعادة. ولكن تأتي هذه المشكلة.

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

يمكن حل ذلك باستخدام تعدد الأشكال.

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

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

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

ألق نظرة على رسم تخطيطي لتنفيذ الأشكال الهندسية. يعيدون استخدام واجهة مشتركة لحساب مساحة السطح والمحيط:

وجود هذه الشخصيات الثلاث وراثة الوالد Figure Interfaceيتيح لك إنشاء قائمة مختلطة triangles، circlesو rectangles. ونعاملهم مثل نفس النوع من الأشياء.

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

إذا كانت لديك دالة تعمل مع شكل باستخدام معاملتها ، فلا داعي لتعريفها ثلاث مرات - مرة واحدة لمثلث ودائرة ومستطيل.

يمكنك تحديده مرة واحدة وقبول ملف Figureكحجة. سواء مررت بمثلث أو دائرة أو مستطيل - طالما أنها تنفذ CalculateParamter()، لا يهم نوعها.

آمل أن يكون هذا قد ساعد. يمكنك استخدام نفس هذه التفسيرات مباشرة في مقابلات العمل.

إذا وجدت شيئًا لا يزال من الصعب فهمه - فلا تتردد في طرحه في التعليقات أدناه.

ماذا بعد؟

يعد الاستعداد للإجابة على أحد كلاسيكيات أسئلة المقابلة الشخصية أمرًا رائعًا - لكن في بعض الأحيان لا يتم استدعائك لإجراء مقابلة.

بعد ذلك ، سأركز على ما يريد أصحاب العمل رؤيته في مطور مبتدئ وكيفية التميز عن الآخرين عند البحث عن وظيفة.

ترقب.