كود التفعيل

57473037814514058742132154134125845684712774124870852147492234782821478245821784215837524981315874667021013754872345757

اخر المستجدات

    حلول بلوجر

أساسيات و مفاهيم يجب عليك إدراكها حول البرمجة كائنية التوجه OOP ( الجزء الرابع - الـ Access Modifiers)


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

  1. أساسيات و مفاهيم يجب عليك إدراكها حول البرمجة كائنية التوجه OOP ( الجزء الأول - تمهيد )
  2. أساسيات و مفاهيم يجب عليك إدراكها حول البرمجة كائنية التوجه OOP ( الجزء الثاني - Classes)
  3. أساسيات و مفاهيم يجب عليك إدراكها حول البرمجة كائنية التوجه OOP ( الجزء الثالث - الـ Objects)

في الجزء الرابع صديقي، سنراجع معك مفهوم الـ Access Modifiers، او إن صحت الترجمة  " معدلات الوصول "، سنناقش معك أهم أنواعها ، و اهم الإختلافات بينها، و سنستعرض مثالا سابقا من الـ Objects لتحديد الـ Access Modifiers و إخضاعها للتجريب . 

أساسيات و مفاهيم يجب عليك إدراكها حول البرمجة كائنية التوجه OOP ( الجزء الرابع - الـ Access Modifiers)

ما هي الـ Access Modifiers : 

الـ Access Modifiers و دعني أترجمها في هذا المقال ب " معدلات الوصول " سواء كانت الترجمة صحيحة ام خاطئة فنحن بصدد شرحها و تفسيرها بشكل صحيح بالتأكيد، و هي عبارة عن كود برمجي او كلمة برمجية إن صح التعبير تقوم بتحديد خاصية الوصول لأي وصف او Field او Properity و كذا الـ functions او Actions داخل الكلاس الخاص بك، بحيث يمكن تحديد لعنصر معين الوصول الكامل من طرف أي كلاس اخر او Object اخر، بينما يمكن منع الوصول إليه او التعديل عليه . 
بالأخذ بالمثال السابق الخاص بدرس الكلاس : 

أساسيات و مفاهيم يجب عليك إدراكها حول البرمجة كائنية التوجه OOP ( الجزء الرابع - الـ Access Modifiers)


قمنا بإستخدام كلمة Public قبل عمل Initialization لكل من الـ Fields و الـ Actions، عندما شرحنا الكلاس اشدت عن عبارة " Public " و أخبرتك ان تتجاوزها في الوقت الراهن لأننا سنشرحها لاحقا و قد حان الوقت لفعل ذلك في هذا الدرس، ثم في درس الـ Object عندما قمن بصناعة الـ Object و الإطلاع على الـ Fields و كذا الـ Actions التي يمكن الوصول إليها من طرف الـ Object وجدنا النتيجة كالتالي : 

أساسيات و مفاهيم يجب عليك إدراكها حول البرمجة كائنية التوجه OOP ( الجزء الرابع - الـ Access Modifiers)

وجدنا ان الـ Object يستطيع الوصول لكل من الـ id و motherboard و غيرها، كذا الـ Actions التي تم صناعتها داخل الكلاس، و قد إستطاع فعل ذلك بسبب عامل الـ Access Modifier الذي هو في هذه الحالة Public .

- الخاصية Public : 

هو أول Access Modifier معنا في هذا الدرس، و ترجمة عبارة Public هي عام، أي ان شخص يستطيع الوصول إلى ذلك الـ Field او Action مادام يحمل " تعديل وصول " من نوع Public، لذلك إستطعنا من خلال الـ Object الوصول لكل الـ fields و الـ Actions الموجودة في الكلاس بخاصية Public

يمكننا إستخدام Public كـ Access Modifier نهائي، أي النتيجة النهائية لكل من الـ Fields و الـ Actions التي نريد من الـ Object ( او كلاس اخر سنصل لهذه المرحلة في موضوع الوراثة ) ان يحصل عليها، فإن كان لدي على سبيل المثال احد الـ Actions التي تتطلب إشتغال Actions اخر، او ببساطة Function تعتمد على Function أخرى للعمل، فعلي جعل الـ Function النهائية بخاصية Public لكي يستطيع الـ object في الأخير إستخدامها، اما الـ Function المساعدة فلا يجب عليك جعلها كذلك لأن الـ Object ليس له الحق في استخدامها لأنها مجرد دالة مساعدة للدالة الأصلية و هنا لا يصح إستخدام Public

- الخاصية Private : 

لم نستخدمها مسبقا، لكنها الأكثر إستخداما أثناء صناعة كلاس، في الحقيقة، الكلاس الذي قمنا بصناعته في الأعلى هو في الحقيقة غير محمي و غير صحيح، فالـ Fields كلها يجب ان تتضمن خاصية Private و جعل الوصول لها من خلال الـ Getters و الـ Setters فقط ( لا تقلق، سنشرح لك كل هذا في سلسلة هذه المقالات ) . 
خاصية Private ، هو Access Modifier يمنع الوصول الكلي للـ Fields من خلال أي طرف ثاني، و يبقى  إستخدامه منوطا فقط داخل الكلاس الخاصة به، في في حالة الكلاس الخاصة بنا، إن قمنا بتحويل كل من الـ id و ram و كل الـ fields من Public الى Private، فإن الـ Object الذي سنصنعه لاحقا لن يستطيع إطلاقا الوصول لها لأن " حق الوصول " هو حق خاص Private بالكلاس فقط، إليك مثالا عن كل هذه الطلاميس التي أخبرتك بها : 




تذكر أننا نشتغل دائما في نفس المشروع و نفس الأكواد البرمجية التي إستعرضناها في كل من الدروس السابقة، إن دققت النظر جيدا، فقد قمنا بتغيير " معدلات الدخول " لكل من الـ Fields في الكلاس الخاصة بنا الى Private، في حين تركنا معدلات الدخول الخاص بالـ Actions اعتيادية او Public حتى نستطيع ان نرى الفرق جيدا . 
حين قيامنا بصناعة الـ Object و محاول إستخدام الـ Fields، نجد ان الـ Object (اي حاسوب Acer ) لا يوفر لنا الوصول للـ Fields إطلاقا على عكس الدرس السابق في الـ Object، في حين نرى إمكانية الوصول للـ Actions لأن حق الوصول الخاص بها لازال Public . 

ربما ستطرح السؤال الآن، و ما الفرق؟ اعني لما سأستغني عن Public و أضع Private، ما الفائدة منه، لما سأستخدمها من أصله ؟ الجواب متعدد الأبعاد، فأولا الكلاس الخاص بنا بسيط لذلك لن يظهر لك جليا الإستخدام، لكن تخيل كلاس بأزيد من 15 Field، بعض الـ Fields تعتمد على Fields أخرى من أجل العمل، فمثلا لدي كل من birthDate ( تاريخ الميلاد ) و كذا الـ Age ( او العمر ) ماذا لو أردت ان اقوم بإعطاء قيمة الـ Age إنطلاقا من birthdate ؟ في هذه الحالة سيتوجب علي ان اجعل Field الخاص بالعمر Private لأني سأقوم شخصيا بإعطائه القيمة إنطلاقا من تاريخ الولادة اوتوماتيكيا ، و ليس إإدخاله عن طريق الـ Object ، ستتكون لدينا الفكرة بشكل أكبر في مقال الـ Getters و الـ Setters . 

- الخاصية Protected : 

من الفقرتين السابقتين، ستصل تقريبا الى خلاصة ان Public خاصية تمكن الكل من الوصول الى ذلك field او Action،  و أن خاصية Private تمكن فقط الكلاس الأم الأصلية التتي تتضمن تلك الـ fields من الوصول إليها، فما دور Protected إذن ؟ 
خاصية Protected او " محمي "، و هو نوع من الـ Access Modifiers بحث ان الوصول يكون متعلقا بالكلاس الأم و الكلاسات التي ترث منها . 
ماذا ؟ ترث منها ؟ كلاس أخرى من غير الكلاس الأصلية ؟ نعم، يمكن صناعة أزيد من كلاس، و يمكن لكل كلاس ان تكون اما مستقلة عن أخرى ( مثلا في مشروعنا هذا سنحتاج الى كلاس الحاسوب من أجل إنشاء حاسوب، و قد نحتاج الى كلاس مستخدم من أجل تكوين المستخدم الخاص بالبرنامج مثل الادمن او المستخدم العادي ) كما يمكن لكلاس ان تكون مرتبطة بكلاس اخرى عبر ما يسمى بالوراثة Inheretance، في هذه الحالة ( سيأتي الدور عليها في احد المقالات نعدك بهذا ) ، في حالة  الوراثة، لا يمكن لخاصية Private ان تنقل نفس العناصر الى الكلاس الاخرى رغم الوراثة، و خاصية Public تستطيع فعل ذلك لكنها ستنقل لنا العناصر للـ Objects كذلك، فمن أجل تجاوز هذا الأمر، نستخدم Protected، بحيث ان العنصر الذي يحمل Access من نوع Protected نستطيع إستخدامه في الكلاس الخاصة بنا و أي كلاس أخرى ترث من الكلاس الأم . 

ببساطة، كانت هذه هي أهم الـ Access Modifiers، و ستساعدنا كثيرا في المستقبل، و سنستخدمها أكثر من غيرها صدقني، لذلك حاول إستيعابها جيدا في هذا المقال، و إن كان مقالنا غير كافي فلك حرية البحث و نلتقي في مقال مقبل و جزء اخر من سلسلة مقالات مفاهيم و أساسيات يجب إدراكها حول البرمجة كائنية التوجه OOP . 


اترك تعليقا :

ليست هناك تعليقات:

إرسال تعليق