السابق

التالي

ما هي البرمجة الموجهة نحو العنصر؟

مكتمل

البرمجة الموجهة نحو العناصر (OOP) عبارة عن نموذج برمجة. حيث إنها تقوم على فكرة تجميع البيانات ذات الصلة والوظائف في "جزر" من المعلومات. تُعرف هذه الجزر باسم العناصر.

دون النظر إلى النموذج المُستخدم، تستخدم البرامج السلسلة ذاتها من الخطوات لحل المشاكل:

1. إدخال البيانات: تُقرأ البيانات من مكان ما، حيث من الممكن أن تكون البيانات مُخزنة مثل نظام الملفات أو قاعدة البيانات.
2. المعالجة: تُفسر البيانات ورُبمّا تُغير ليتم إعدادها للعرض.
3. إخراج البيانات: تُقدم البيانات بحيث يمكن قراءتها والتفاعل معها إمّا من خلال مستخدم فعلي أو نظام.

OOP في مقابل البرمجة الإجرائية

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

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

وضع نموذج OOP: تحديد المفاهيم

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

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

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

مزايا OOP

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

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

نموذج نظام OOP

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

دراسة حالة نظام إدارة الفواتير

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

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

ما علاقة هذا الوصف بـ OOP؟ إذا كنت اطلعت على سير العمل السابق — والذي غالبًا ما يكون تدفقًا يدويًا — وتحويله إلى برامج مكتوبة، فإن أول شيء ستفعله هو محاولة وضع نماذج للنظام. مع سياق إدارة الفاتورة، يمكنك البدء في رؤية العوامل الفاعلة (العناصر) والسلوكيات والبيانات بقراءة وصف المجال المشكلة.

إذا كنت تفكر في المجال الموصوف على أنه ذو مراحل، وإدخال، ومعالجة، وإخراج، يمكنك البدء في تعبئة بنود الجدول التالي:

المرحلة	ماذا
الإدخال	الفاتورة
قيد المعالجة	الفرز، والموافقة، والرفض
الإخراج	السداد

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

البحث عن العناصر والبيانات والسلوك

يمكنك العثور على الأدوات المختلفة للنظام الخاص بك من خلال طرح أسئلة مثل:

• من يتفاعل مع من؟
• من يفعل ماذا ولصالح من؟

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

1. خدمة البريدتسلّمفاتورة إلى النظام.

2. تخضعالفاتورة لعملية الفرزإما من خلال تعليمة برمجية للمرجع أو يدويًا من خلال الفارز للتأكد من أنه ينتهي في القسم الصحيح.

3. يصبح invoice إمّا approved أو rejected من خلال approver بناءً على عوامل مثل، على سبيل المثال، صحة وحجم amount.

4. تخضع الفاتورة لعمليةالدفع من خلال معالج الدفع باستخدام معلومات الدفع المُقدمة.

يمكنك الآن استخراج الكائنات والبيانات والسلوك من الجمل وتنظيمها في جدول، على هذا النحو التالي:

المرحلة	الفاعل	سلوك	بيانات
الإدخال	خدمة البريد	يسلم	الفاتورة
الإدخال	النظام	يتلقى	الفاتورة
قيد المعالجة	وحدات فرز أو نظام	فرز أو توجيه	فاتورة (تعليمة برمجية مرجعية)
قيد المعالجة	الموافق	الموافقة أو الرفض	الفاتورة (المبلغ)
الإخراج	معالج الدفع	يدفع	الفاتورة (معلومات الدفع)

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

إشعار

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

متابعة