الفصل 3: المنحى الكائني
في هذا الفصل سوف نلقي نظرة على مفهوم المنحى الكائني Object Orientation (OO) . لقد تمّ تصميم لغة النمذجة الموحّدة UML بحيث تدعم المنحى الكائني ، لذلك سنقوم بتعريف مفاهيمه قبل
التعمق في لغة UML ،
و استكشاف المزايا التي قد يوفرّها.
البرمجة المهيكلة
أولا، لنختبر بصورة سريعة كيف يتم تصميم الأنظمة
البرمجية باستخدام الاتجاه المهيكل (أحيانا يُسمّى وظائفي Functional).
في البرمجة المهيكلة Structured Programming، الطريقة العامة المتّبعة هي النظر إلى المسألة، ثم تصميم
مجموعة من الوظائف functions
التي يمكنها انجاز المهام المطلوبة لحلها. إذا تضخّمت هذه الوظائف ، يتم
تجزئتها حتى تصير صغيرة بالحدّ الذي يتيسّر فيه مناولتها و فهمها. هذه العملية
تدعى التفكيك الوظائفي functional decomposition.
ستحتاج معظم الوظائف إلى بيانات من نوع ما لتعمل
عليها. البيانات في الأنظمة الوظائفية عادة ما يحتفظ بها في قاعدة بيانات من نوع
ما (أو قد يحتفظ بها في الذاكرة كمتغيّرات عامة global variables).
لنأخذ مثالا بسيطا، تخيّل منظومة لإدارة معهد، هذه
المنظومة تحتفظ ببيانات الطلبة و المدرّبين في المعهد إضافة للمعلومات حول الدورات
المتوفرة، كذلك تقوم المنظومة بتتبع كل طالب و المقررات التي التحق بها.
التصميم الوظائفي المحتمل سيتضمّن كتابة الوظائف
functions
التالية:
add_student إضافة طالب
enter_for_exam دخول امتحان
check_exam_marksفحص علامات امتحان
issue_certificateإصدار شهادة
expel_student طرد طالب
سوف نحتاج أيضا إلى نموذج بيانات data model ليمثّل هذه الوظائف. نحتاج لتخزين معلومات عن الطلبة، و
المدربين و الامتحانات و المقررات، لذا يجب علينا تصميم مخطط قاعدة بيانات database schema للاحتفاظ بهذه البيانات.
شكل 9: مخطط قاعدة بيانات بسيط. الخطوط المنقطّة
تشير إلى اعتمادية مصفوفة بيانات على أخرى، مثلا، كل طالب يتم تدريبه بواسطة عدة
مدرّبين.
الآن بدأ واضحا أن الوظائف functions التي حدّدناها سابقا سوف تعتمد على هذه المصفوفة من
البيانات. مثلا، وظيفة "add_student"
(إضافة طالب) ستقوم بتغيير محتويات "Students" (طلبة)، و وظيفة "issue_certificate" (إصدار شهادة) تحتاج إلى الوصول إلى بيانات طالب "Student" (لمعرفة تفاصيل الطالب الذي يحتاج للشهادة) و ستحتاج
الوظيفة أيضا إلي بيانات الامتحانات "Exam"
.
المخطط diagram
التالي عبارة عن رسم لكل الوظائف، مجتمعة رفق البيانات، و رسمت الخطوط فيها
حيثما وجدت اعتمادية dependency .
شكل 10: خريطة الوظائف، و البيانات و الاعتماديات.
المشكلة مع هذه المقاربة؛ أن المسألة
التي نتعامل معها إذا ما تعقدت أكثر فإن صعوبة المحافظة على
المنظومة و صيانتها ستزداد. فإذا أخذنا المثال أعلاه، ماذا سيحدث لو تغيّرت
المتطلبات requirements
بطريقة تؤدّي إلى تغيير أسلوب مناولة بيانات الطالب Student.
كمثال، لنتخيّل أن منظومتنا تعمل على أكمل ما يكون،
لكننا اكتشفنا أن تخزين تاريخ ميلاد الطالب على شكل عدد ذو خانتين كي يمثل
السنة كانت فكرة سيّئة، الحل المبدئي هنا هو أن نقوم بتغيير حقل تاريخ
الميلاد في جدول الطلبة Students
من خانتين إلى أربع خانات لرقم السنة.
المشكلة الجدية لهذا التغيير تنبع من أنه قد يسبّب
في ظهور آثار جانبية غير متوقعة. فبيانات جدول الامتحانات Exam و جدول المقررات Courses و
جدول المدرّبين Tutors تعتمد كلها (بطريقة أو بأخرى)
على بيانات جدول الطالب Students،
لذا قد نتسبب في كسر بعض العمليات بتغييرنا البسيط هذا، و إعاقة
وظائف add_student و enter_for_exams و issue_certificate و
expel_student ،
فوظيفة add_student لن تعمل
بالتأكيد لأنها تتوقع أن تكون المعلومة الخاصة بسنة الميلاد على شكل رقم
بخانتين بدلا من أربع.
إذا، لدينا معدل كبير من المشاكل
المحتملة، و الأسوأ أننا لن نستطيع بسهولة تعيين أماكن الاعتمادية في التوليف code التي ستتأثر بهذا التغيير.
كم من مرّة قمت بتعديل سطر في التوليف و بكل
براءة و دون أن تعي أنك سبّبت عن غير قصد في كسر عمليات أخرى قد تبدو لا
علاقة لها في الظاهر؟
إشكالية عام 2000 (ثغرة الألفية) ذات التكلفة
العالية كان سببها بالضبط هذه المشكلة. فحتى لو أن حلها يفترض فيه أن يكون بسيطا
(تغيير كل حقل سنة من خانتين إلى أربع) فإن التداعيات المحتملة لهذا التغيير
البسيط يجب التحقق منها و فحصها بدقة.
أسلوب المنحى الكائني
يحاول المنحى الكائني "OO" التقليل من تأثير هذه المشكلة عن طريق الجمع بين البيانات data و الوظائف functions
ذات العلاقة في قالب module واحد.
بالنظر إلى الشكل 10 أعلاه، يبدو واضحا وجود علاقة
بين البيانات و الوظائف؛ فمثلا وظيفتا: add_student و
expel_student مرتبطتان
بقوة ببيانات Student
الطالب.
الشكل التالي يبيّن التجميعات الكلّية للبيانات و الوظائف
ذات العلاقة على شكل قوالب:
شكل 11: البيانات و الوظائف المرتبطة موضوعة في
قوالب.
بعض النقاط الجديرة بالملاحظة حول نظام
القولبة الجديد في البرمجة:
·
أكثر من تمثل لنفس
القالب يمكن استحضاره عند تشغيل البرنامج. في منظومة المعهد، سيكون هناك تمثل
لقالب Student لكل
طالب يتبع المعهد يجرى التعامل معه في المنظومة. و كل تمثل سيكون له بياناته
الخاصة. (بالطبع لكل تمثل اسما مختلفا).
·
القوالب يمكنها
"التخاطب" مع قوالب أخرى عن طريق استدعاء وظائفها. مثلا،
عندما يتم استدعاء وظيفية "add" (إضافة) في Student
(الطالب) ، سيتم خلق تمثلا جديدا
لقالب Student ، و بعدها سيتم
استدعاء وظيفة "add_attendee" (إضافة مشترك) من التمثل المناسب لقالب "Course" دورة.
التغليف
Encapsulation
الأمر الأساسي هنا، أنه لا يتم السماح بقراءة أو
تغيير أي عنصر في البيانات إلا من قبل التمثّل الذي تتبعه هذه
البيانات . فمثلا، التمثل الخاص بقالب المدرّب Tutor
لا يمكنه تحديث أو قراءة بيانات "age"
العمر داخل قالب Student الطالب.
هذا المفهوم يسمّى بالتغليف Encapsulation ،
الذي يسهم في جعل هيكل المنظومة أكثر متانة، و يجنّبها الحالة التي تعرّضنا
لها سابقا، حيث التغيير البسيط في جزء من البيانات قد يؤدّي إلى تغييرات
متتابعة و أكثر عمقا.
بواسطة هذا التغليف، يمكن للمبرمج الذي يتعامل مع
قالب Student مثلا
أن يقوم بتغيير بيانات القالب بكل أمان و دون الخشية من وجود قوالب أخرى مرتبطة أو
تعتمد على هذه البيانات. قد يحتاج المبرمج إلى تحديث الاجرائيات داخل القالب، و
لكن التأثير سيبقى محصورا داخل قالب واحد معزول عن القوالب الأخرى.
الكائنات Objects
خلال هذا الفصل، أشرنا إلى هذه التجميعات من
البيانات و الوظائف المرتبطة بأنها قوالب "modules". عموما إذا نظرنا إلى خصائص هذه القوالب سنجد مرادفات لها
في العالم الحقيقي.الكائنات Objects في
عالم الواقع يمكن تمييزها بشيئين : كل كائن في عالم الواقع لديه بيانات data و سلوك behaviour .
فمثلا جهاز التلفاز هو كائن و يعالج البيانات بطريقة تجعلها تنضبط في
قناة محددة، يتم تحديد معدّل المسح إلى قيمة معيّنة، كذلك معدّل التباين و
شدّة الإضاءة و هكذا. التلفاز أيضا يمكنه أن "يقوم" بأشياء،
التلفاز يمكنه التشغيل أو الإقفال، القنوات يمكن تغييرها، و هكذا.
يمكننا تمثيل هذه المعلومات بنفس أسلوب القوالب
البرمجية السابقة:
شكل 12: بيانات و سلوك جهاز التلفاز
على المنوال نفسه إذا، فإن "كائنات"
العالم الحقيقي بالإمكان قولبتها بطريقة مشابهة للقوالب البرمجية التي سبق
مناقشتها.
لهذا السبب، نسمّي هذه القوالب بالكائنات Objects و منها جاء مصطلح البرمجة / التصميم بالمنحى الكائني Object Oriented Design/Programming.
حيث أن نظمنا البرمجية تقدّم حلولا لمشاكل حقيقية في
واقعنا (سواء كان ذلك نظام تسجيل في معهد، أو نظام إدارة مخازن، أو نظام
توجيه صواريخ)، يمكننا تحديد الكائنات في العالم الواقعي و بسهولة نقوم بتحويلها إلى
كائنات برمجية.
بكلمات أخرى، يقدم المنحى الكائني تجريدا
أو تمثيلا أفضل للعالم الحقيقي أو الواقع. نظريا، هذا يعني أنه إذا
تغيّر الواقع (كتغيّر المتطلبات) فان تغيير الحلول أو تعديلها سيكون أسهل، ما
دامت الخطوط الرابطة بين مشاكل الواقع و الحلول الموضوعة لها واضحة.
مصطلحات
البيانات data
الخاصة بالكائن object تسمّى
عادة بخصائص أو سمات Attributes الكائن.
و تسمّى التصرّفات المختلفة التي يقوم بها الكائن طرق أو نهجيات Methods الكائن. النهجيات هي مرادف لما يعرف في لغات البرمجة بالوظائف functions أو الإجرائيات procedures .
المصطلح الآخر المشهور في هذا السياق هو Class الصنفية. الصنفية أو الصنف هي ببساطة أرضية (template) يقوم عليها الكائن. يتم في الصنفية وصف السمات attributes و النهجيات methods
التي ستكون حاضرة لكل تمثلات أو تجسّدات الصنفية. في منظومة المعهد التي تكلّمنا
عنها في هذا الفصل، كان لدينا صنفية تسمّى Student.
سمات attributes صنفية الطالب Student Class كانت الاسم و العمر و ما إلى ذلك، أما النهجيات methods فكانت add و expel. في التوليف code
سنحتاج لتحديد هذه الصنفية لمرة واحدة فقط. و حالما يتم تشغيل التوليف ،
يمكننا خلق create تجسّدات/تمثلات
instances لهذه
الصنفية أو بعبارة أخرى: إنشاء كائنات objects
الصنفية.
كل كائن منها سيمثل طالبا محددا، و كل منها أيضا
سيحوي ما يخصّه من قيم البيانات.
إستراتجية المنحى الكائني
بالرغم من أن هذا الفصل قد لمس
باختصار فوائد المنحى للكائن (مثل: منظومات أكثر ثباتا، تمثيل أفضل للواقع)،
إلا أننا تركنا بعض الأسئلة بدون إجابة. كيف نميّز الكائنات التي نحتاجها عند
تصميمنا لمنظومة ما؟ ما هي النهجيات methods
و السمات attributes
المفترض وجودها؟ ما هو الحجم المناسب للصنفية؟ و غيرها من الأسئلة.
ستنتقل بنا هذه الدروس خلال عمليات تنشئة البرمجيات باستخدام المنحى للكائن (و UML) ، و سنقوم بالإجابة عن كل هذه الأسئلة.
أحد أهم نقاط ضعف المنحى الكائني في الماضي هو
أنها في الوقت الذي تتميّز فيه بأنها قوية على مستوى الصنفية/الكائن، إلا أنها
ضعيفة عند التعبير عن سلوك المنظومة ككلّ. النظر من خلال الصنفيات شيء جيّد،
لكن الصنفيات في حد ذاتها هي مجموعات لكينونات على مستوى منخفض و لا
يمكن لها أن تصف ما تقوم به المنظومة ككل. باستخدام الصنفيات فقط فإن
الأمر يشبه محاولة فهم كيفية عمل الحاسوب من خلال فحص مكونات اللوحة الأم!
الاتجاه الحديث و المدعوم بقوة من قبل UML هو نسيان كلّ ما يتعلّق بالكائنات و الصنفيات في
المراحل المبكّرة للمشروع، و التركيز بدل ذلك على ما يجب أن تكون المنظومة قادرة
على القيام به. بعد ذلك، و مع تقدّم العمل في المشروع يتم تدريجيا بناء الصنفيات
لتجسيد النواحي الوظيفية للمنظومة المطلوبة. في هذه الدروس سنتتّبع هذه
الخطوات بدءاً من التحاليل الأوّلية و حتى تصميم الصنفية.
ملخص
·
المنحى الكائني
طريقة تفكير تختلف عن الاتجاه المهيكل.
·
نقوم بالجمع بين
البيانات و التصرفات ذات العلاقة داخل صنفيات.
·
ثم يقوم برنامجنا
بخلق تجسّدات/ تمثلات للصّنفية، بشكل كائنات.
·
الكائنات يمكنها
التعاون مع بعضها البعض، من خلال مخاطبة نهجياتها.
·
البيانات في
الكائن مغلّفة و لا يقوم بتعديلها إلا الكائن نفسه.
قد يعجبك ايضا