❓ استخدام super للوصول لحقل الأب
class A {
int x = 5;
}
class B extends A {
int x = 10;
int get(){ return super.x; }
}
B b = new B();
System.out.println(b.get());int[] arr = {2, 4, 6, 8};
int sum = 0;
for(int i = 0; i < arr.length; i += 2){
sum += arr[i];
}
System.out.println(sum);من ابرز الكتب المشهوره في مجال OOP سنقوم ان شاء الله بتنزيل ملخص للكتاب بالغة العربية بشرح بسيط و جداً مفهوم
المحتوى منقول من صفحة المهندس المصري abdulaziz aldeeb على فيسبوك
المحتوى منقول من صفحة المهندس المصري abdulaziz aldeeb على فيسبوك
شاركوا رابط القناة لكي تعم الفائدة وجزاكم الله الف خير
❤2
عبدالوهاب العليوي | Abdulwahab Al-Alawi
Photo
اول منشور
هنبدأ نتكلم عن كتاب Object-Oriented Thought Process وإن شاء الله نحاول نلخص أهم الأفكار في الكتاب.
الكاتب بدأ الكتاب بحرفين بس وهما OO ومش OOP، وبالتالي في سبب
مهم للتسمية دي، وهو أنه بيقول إن أغلب الناس بتبدأ تتعلم الـOO وهي بتتعلم لغة البرمجة، مثلًا زي C++ أو C#، بحيث إنه دخل على طول في مفهوم الـOOP وهو بيتعلم لغة البرمجة كأنها جزء منها، ولكن الحقيقة إن الـOO ليها طريقة تفكير مختلفة تمامًا، وما ينفعش حد يتعلمها كأنها أداه أو جزء من لغة معينة. وعلشان كدا الكاتب بيقول إنك بمجرد ما تفهم الـOO هتفهم كويس كل المصطلحات التانية زي الـOOA والـOOD والـOOP.
الفرق بين الـOO والـProcedural: هنا الكاتب بيتكلم عن فرق قوي جدًا بين البرمجة الإجرائية وما بين الـOO. والفرق الجوهري ده في كلمة Both، أو كلاهما. والكلمة دي عائدة على الخصائص والسلوكيات، والمقصود هنا هو إن الـOO قدرت تجمعلك البيانات والوظائف في مكان واحد مقفول عليهم، وده بالظبط مفهوم الـEncapsulation، على عكس الـProcedural اللي عبارة عن سلوكيات (وظائف) منفصلة عن الخصائص أو الداتا. يعني ممكن الداتا تبقى في الـGlobal عادي خالص، وأي حد يقدر يوصلها وكمان يقدر يعدل عليها. وبالتالي مفيش تحكم في الداتا بتاعتي أصلًا لأنها متاحة لكل الوظائف.
وبالتالي المقصود بكلمة Both هنا معناه إن ال OO قدرت تجمعلك الأتنين مع بعض في نفس المكان والعملية دي بنقول عليها Encapsulation.
مفهوم الـEncapsulation: الكاتب عرف الـEncapsulation إنه عملية تجميع الخصائص والسلوكيات في مكان واحد، والحقيقة ده كلام مظبوط، ولكني عايزك تفرق ما بين التطبيق السليم والمظبوط للمفهوم وما بين المفهوم نفسه. يعني بكل بساطة أنا أقصد إن كل حاجة ليها طرق كتير جدًا علشان تتنفذ، يعني ممكن أقول أنا لما عملت تجميع للـAttributes والـMethods في مكان واحد وبكدا عملت Encapsulation. كلامك صح، بس هل دي أفضل Encapsulation ممكنة؟ وهنا بقى بيدخل معانا مفهوم جديد بيعزز الـEncapsulation ويخليه أقوى، والمفهوم ده هو الـData Hiding.
مفهوم الـData Hiding: إحنا قولنا إن بمجرد ما عملنا تجميع للخصائص (Fields) والسلوكيات (Methods) في مكان واحد وهو الـClass، وقولنا إن ده كدا اسمه Encapsulation، بس الحقيقة إن كل مفهوم ليه مستويات من القوة، وعلشان نوصل لقوة الـEncapsulation لازم نشرح مفهوم الـData Hiding، وهو بكل بساطة كدا بيقولك بما إنك جمعت السلوكيات (Methods) والخصائص (Attributes) في مكان واحد، بقيت قادر تمنع أو تسمح بالوصول لبعض الخصائص والسلوكيات.
ملحوظة: الكاتب بيقول إن مصطلح ال Object Data أو بيانات الكائن في سياق الـOOP بنقول عليها Attributes. والسلوكيات أو الوظائف بنقول عليها Methods. وبيقولك إن التحكم في الوصول لأي من الـMethods أو الـAttributes بنقول عليه Data Hiding.
يعني بكل بساطة كدا الـData Hiding مش بس تخص التحكم في الوصول للـ Attributes ، لكن بتتحكم في الوصول للـAttributes والـMethod مع بعض عن طريق ما يسمى بالـAccess Modifiers، ودي مسموح تستخدمها سواء مع الـAttributes أو مع الـMethod.
الـAccessors والـMutator: أحيانًا تسمى بالـSetters والـGetters. المفهوم ده بكل بساطة قدرنا نعمله بسبب وجود الـData Hiding. والفكرة كلها في الموضوع إنك بتمنع الوصول لل Attributes وبتخليها private وتسمح بالوصول ليها عن طريق وظائف public. والميزة دي قوية جدًا وبتعملك control قوي جداً على الداتا بتاعتك، وهنتكلم على الموضوع ده تاني بعدين. وعلشان أوضحلك جزء بسيط أوي من أهميتها خلينا نقول أنت عندك كلاس أسمه Date وجواه طبعاً Day و Month و Year لو أحنا مش عاملين الخصائص دي private وكان أي حد يقدر يعدل عليها ممكن يخليلك ال Month يبقي ب 13 مثلاً, وممكن يخليلك اليوم ب 32 مثلاً وده مش منطقي لأن أخر حاجه في الشهور 12 وأخر حاجه في عدد الأيام في الشهور هو 31 وكمان علي حسب الشهر. وبالتالي لما بتعمل Setter بشكل مظبوك بتقدر تحط لوجيك معين علشان يمنع أي تعديل مش مظبوط علي ال Object بتاعك.
كفايه لحد هنا علشان المنشور بقي طويل أوي, المره الجايه هنكمل كلامنا مع الفصل الأول.
صفحة المهندس على فيسبوك
Abdulaziz aldeeb
#ملخص #oop #شرح
هنبدأ نتكلم عن كتاب Object-Oriented Thought Process وإن شاء الله نحاول نلخص أهم الأفكار في الكتاب.
الكاتب بدأ الكتاب بحرفين بس وهما OO ومش OOP، وبالتالي في سبب
مهم للتسمية دي، وهو أنه بيقول إن أغلب الناس بتبدأ تتعلم الـOO وهي بتتعلم لغة البرمجة، مثلًا زي C++ أو C#، بحيث إنه دخل على طول في مفهوم الـOOP وهو بيتعلم لغة البرمجة كأنها جزء منها، ولكن الحقيقة إن الـOO ليها طريقة تفكير مختلفة تمامًا، وما ينفعش حد يتعلمها كأنها أداه أو جزء من لغة معينة. وعلشان كدا الكاتب بيقول إنك بمجرد ما تفهم الـOO هتفهم كويس كل المصطلحات التانية زي الـOOA والـOOD والـOOP.
الفرق بين الـOO والـProcedural: هنا الكاتب بيتكلم عن فرق قوي جدًا بين البرمجة الإجرائية وما بين الـOO. والفرق الجوهري ده في كلمة Both، أو كلاهما. والكلمة دي عائدة على الخصائص والسلوكيات، والمقصود هنا هو إن الـOO قدرت تجمعلك البيانات والوظائف في مكان واحد مقفول عليهم، وده بالظبط مفهوم الـEncapsulation، على عكس الـProcedural اللي عبارة عن سلوكيات (وظائف) منفصلة عن الخصائص أو الداتا. يعني ممكن الداتا تبقى في الـGlobal عادي خالص، وأي حد يقدر يوصلها وكمان يقدر يعدل عليها. وبالتالي مفيش تحكم في الداتا بتاعتي أصلًا لأنها متاحة لكل الوظائف.
وبالتالي المقصود بكلمة Both هنا معناه إن ال OO قدرت تجمعلك الأتنين مع بعض في نفس المكان والعملية دي بنقول عليها Encapsulation.
مفهوم الـEncapsulation: الكاتب عرف الـEncapsulation إنه عملية تجميع الخصائص والسلوكيات في مكان واحد، والحقيقة ده كلام مظبوط، ولكني عايزك تفرق ما بين التطبيق السليم والمظبوط للمفهوم وما بين المفهوم نفسه. يعني بكل بساطة أنا أقصد إن كل حاجة ليها طرق كتير جدًا علشان تتنفذ، يعني ممكن أقول أنا لما عملت تجميع للـAttributes والـMethods في مكان واحد وبكدا عملت Encapsulation. كلامك صح، بس هل دي أفضل Encapsulation ممكنة؟ وهنا بقى بيدخل معانا مفهوم جديد بيعزز الـEncapsulation ويخليه أقوى، والمفهوم ده هو الـData Hiding.
مفهوم الـData Hiding: إحنا قولنا إن بمجرد ما عملنا تجميع للخصائص (Fields) والسلوكيات (Methods) في مكان واحد وهو الـClass، وقولنا إن ده كدا اسمه Encapsulation، بس الحقيقة إن كل مفهوم ليه مستويات من القوة، وعلشان نوصل لقوة الـEncapsulation لازم نشرح مفهوم الـData Hiding، وهو بكل بساطة كدا بيقولك بما إنك جمعت السلوكيات (Methods) والخصائص (Attributes) في مكان واحد، بقيت قادر تمنع أو تسمح بالوصول لبعض الخصائص والسلوكيات.
ملحوظة: الكاتب بيقول إن مصطلح ال Object Data أو بيانات الكائن في سياق الـOOP بنقول عليها Attributes. والسلوكيات أو الوظائف بنقول عليها Methods. وبيقولك إن التحكم في الوصول لأي من الـMethods أو الـAttributes بنقول عليه Data Hiding.
يعني بكل بساطة كدا الـData Hiding مش بس تخص التحكم في الوصول للـ Attributes ، لكن بتتحكم في الوصول للـAttributes والـMethod مع بعض عن طريق ما يسمى بالـAccess Modifiers، ودي مسموح تستخدمها سواء مع الـAttributes أو مع الـMethod.
الـAccessors والـMutator: أحيانًا تسمى بالـSetters والـGetters. المفهوم ده بكل بساطة قدرنا نعمله بسبب وجود الـData Hiding. والفكرة كلها في الموضوع إنك بتمنع الوصول لل Attributes وبتخليها private وتسمح بالوصول ليها عن طريق وظائف public. والميزة دي قوية جدًا وبتعملك control قوي جداً على الداتا بتاعتك، وهنتكلم على الموضوع ده تاني بعدين. وعلشان أوضحلك جزء بسيط أوي من أهميتها خلينا نقول أنت عندك كلاس أسمه Date وجواه طبعاً Day و Month و Year لو أحنا مش عاملين الخصائص دي private وكان أي حد يقدر يعدل عليها ممكن يخليلك ال Month يبقي ب 13 مثلاً, وممكن يخليلك اليوم ب 32 مثلاً وده مش منطقي لأن أخر حاجه في الشهور 12 وأخر حاجه في عدد الأيام في الشهور هو 31 وكمان علي حسب الشهر. وبالتالي لما بتعمل Setter بشكل مظبوك بتقدر تحط لوجيك معين علشان يمنع أي تعديل مش مظبوط علي ال Object بتاعك.
كفايه لحد هنا علشان المنشور بقي طويل أوي, المره الجايه هنكمل كلامنا مع الفصل الأول.
صفحة المهندس على فيسبوك
Abdulaziz aldeeb
#ملخص #oop #شرح
Facebook
Log in or sign up to view
See posts, photos and more on Facebook.
❤2
عبدالوهاب العليوي | Abdulwahab Al-Alawi pinned «شاركوا رابط القناة لكي تعم الفائدة وجزاكم الله الف خير»
عبدالوهاب العليوي | Abdulwahab Al-Alawi
Photo
هنكمل كلامنا مع الفصل الأول من كتاب Object-Oriented Thought Process وهنتكلم عن مفهوم الـ Class والـ Object.
بص يا سيدي، في كلمة حلوة أوي اتقالت عن الـ Class في الكتاب وهي blueprint. لو بحثت عن الكلمة دي في جوجل، هتلاقي صور لمخططات بيوت أو مخططات سيارات، يعني رسومات هندسية بتوضح الشكل النهائي للبيت قبل البناء أو السيارة قبل التصنيع وهكذا. المهم، هو ده بالظبط بقى دور الـ Class.
دلوقتي، في سياق البرنامج بتاعك، لو قولتله: أعملي Object من نوع Car؟ هل هو عارف هيعمل كده إزاي؟ يعني مثلاً هيستنتج Car عشوائي، ولا هيروح يعمل Object فاضي، ولا هيعمل إيه بالظبط؟
الحقيقة هنا إنك طالما قولتله أعمل Object من نوع Car، يبقى لازم يكون عندك Class من نفس النوع اسمه Car، لأن الـ Class ده هو المكان الوحيد اللي فيه كلمة السر بتاعة إزاي هعملك الـ Car. يعني بكل بساطة، لو قولتلك: أعملي كيكة، وإنت ما بتعرفش تعمل كيكة، يبقى لازم على الأقل أديكلك ورقة فيها خطوات عمل الكيكة صح. ونفس العلاقة بالظبط بين الـ Object والـ Class. يعني لو قولتلك أعمل Object من نوع Car، يبقى لازم يكون عندك Class اسمه Car أروح أشوف إنت عايز الـ Car دي تبقى عاملة إزاي بالظبط، صح؟
والمثال بتاع الكاتب كان عن قوالب تشكيل الكعك والبسكويت، وقالك إن الـ Class هو المخطط اللي بيحدد شكل النتيجة النهائية المطلوبة. وبردو المهندس المدني بيصمم المبنى ويعمل مخطط قبل ما يعمل المبنى نفسه. وهنا بردو نفس العلاقة بين الـ Class، اللي هو بمثابة الـ blueprint، وبين المبنى الفعلي نفسه، اللي هو الـ Object.
يعني إنت بتحدد تفاصيل الـ Object، يبقى شكله إزاي بالظبط لما تعمل منه نسخة. يعني كل دور الـ Class إنه يبقى المخطط بتاعك، علشان لما تروح تقوله أعمل Object من الـ Car، يبقى عارف إنه هيروح يلاقي عندك Class اسمه Car، يقوم يشوف إنت قايله يعمل إيه بالظبط جوا الـ Class ده ويعمله.
يعني لو رجعنا لمثال الفرخة ولا البيضة، هتلاقي نفسك مش عارف تحدد مين الأول. لكن مع الـ Class والـ Object، دايمًا الـ Class بييجي قبل الـ Object. يعني إنت أصلاً مش هتعرف تعمل Object قبل ما تعمل الـ Class.
وكمان لو إنت فاهم Database كويس، ممكن تعتبر إن الـ Class هو شكل الجدول والأعمدة وأنواع البيانات لكل عمود في الجدول. أما الـ Object فهو الداتا نفسها بقى، أو الـ Row الفعلي في الجدول.
الحقيقة، بعد كده هتبقى المنشورات على قد المفهوم، لأن الصور مهمة جدًا جدًا، وما ينفعش ندخل المفاهيم في بعض ونتغاضى عن الصورة.
#oop #ملخص
بص يا سيدي، في كلمة حلوة أوي اتقالت عن الـ Class في الكتاب وهي blueprint. لو بحثت عن الكلمة دي في جوجل، هتلاقي صور لمخططات بيوت أو مخططات سيارات، يعني رسومات هندسية بتوضح الشكل النهائي للبيت قبل البناء أو السيارة قبل التصنيع وهكذا. المهم، هو ده بالظبط بقى دور الـ Class.
دلوقتي، في سياق البرنامج بتاعك، لو قولتله: أعملي Object من نوع Car؟ هل هو عارف هيعمل كده إزاي؟ يعني مثلاً هيستنتج Car عشوائي، ولا هيروح يعمل Object فاضي، ولا هيعمل إيه بالظبط؟
الحقيقة هنا إنك طالما قولتله أعمل Object من نوع Car، يبقى لازم يكون عندك Class من نفس النوع اسمه Car، لأن الـ Class ده هو المكان الوحيد اللي فيه كلمة السر بتاعة إزاي هعملك الـ Car. يعني بكل بساطة، لو قولتلك: أعملي كيكة، وإنت ما بتعرفش تعمل كيكة، يبقى لازم على الأقل أديكلك ورقة فيها خطوات عمل الكيكة صح. ونفس العلاقة بالظبط بين الـ Object والـ Class. يعني لو قولتلك أعمل Object من نوع Car، يبقى لازم يكون عندك Class اسمه Car أروح أشوف إنت عايز الـ Car دي تبقى عاملة إزاي بالظبط، صح؟
والمثال بتاع الكاتب كان عن قوالب تشكيل الكعك والبسكويت، وقالك إن الـ Class هو المخطط اللي بيحدد شكل النتيجة النهائية المطلوبة. وبردو المهندس المدني بيصمم المبنى ويعمل مخطط قبل ما يعمل المبنى نفسه. وهنا بردو نفس العلاقة بين الـ Class، اللي هو بمثابة الـ blueprint، وبين المبنى الفعلي نفسه، اللي هو الـ Object.
يعني إنت بتحدد تفاصيل الـ Object، يبقى شكله إزاي بالظبط لما تعمل منه نسخة. يعني كل دور الـ Class إنه يبقى المخطط بتاعك، علشان لما تروح تقوله أعمل Object من الـ Car، يبقى عارف إنه هيروح يلاقي عندك Class اسمه Car، يقوم يشوف إنت قايله يعمل إيه بالظبط جوا الـ Class ده ويعمله.
يعني لو رجعنا لمثال الفرخة ولا البيضة، هتلاقي نفسك مش عارف تحدد مين الأول. لكن مع الـ Class والـ Object، دايمًا الـ Class بييجي قبل الـ Object. يعني إنت أصلاً مش هتعرف تعمل Object قبل ما تعمل الـ Class.
وكمان لو إنت فاهم Database كويس، ممكن تعتبر إن الـ Class هو شكل الجدول والأعمدة وأنواع البيانات لكل عمود في الجدول. أما الـ Object فهو الداتا نفسها بقى، أو الـ Row الفعلي في الجدول.
الحقيقة، بعد كده هتبقى المنشورات على قد المفهوم، لأن الصور مهمة جدًا جدًا، وما ينفعش ندخل المفاهيم في بعض ونتغاضى عن الصورة.
#oop #ملخص
❤2
🍃اللهم صلِّ وسلم على نبينا محمد.
-الكهف و الاكثار من الصلاه على النبي-💗
-الكهف و الاكثار من الصلاه على النبي-💗
عبدالوهاب العليوي | Abdulwahab Al-Alawi
Photo
هنكمل كلامنا مع الفصل الأول من كتاب _Object-Oriented Thought Process_، وهنتكلم عن مفهوم الـ Encapsulation والـ Data Hiding وكمان الـ Interfaces.
هو بيقولك إن التصميم الجيد للـ Class، أو المقبول على الأقل، لازم يمنع الوصول للوظايف اللي مش ضرورية للتحكم في الـ Object. يعني بكل بساطة كده، ما ينفعش تسيب كل حاجة Public كده وتقول أهي ماشية. الحقيقة إن ده تصميم سيء جدًا، ولازم تسمح الوصول بس للوظايف النهائية اللي بتتحكم في الـ Object. وممكن نضيف مثال من عندنا علشان نوضح الفكرة.
مثال السيارة: لو إنت كإنسان Object وعايز تسوق سيارة Object برضو، هتحتاج إيه من السيارة علشان تقدر تسوقها؟ هتحتاج فرامل، هتحتاج تشغّل السيارة، هتحتاج دواسة بنزين، هتحتاج تتحكم في الاتجاهات. يبقى لازم أوفّر Interfaces واضحة ومحددة للتحكم في السيارة دي، وبالتالي لازم الـ Methods دي كلها تبقى Public، صح؟
ملحوظة: الـ Interfaces في السياق ده مقصود بيها الوظايف العامة المسؤولة عن التحكم في الـ Object.
وبالتالي برضو ما ينفعش أخلّي وظايف تانية Public وهي المفروض تبقى Private لأنها مش ضرورية ولا مهمة للمستخدم النهائي. يعني مثلاً: نظام تبريد المحرك، عملية خلط الوقود والهواء في غرفة الاحتراق، نظام ضبط توقيت الصمامات، عملية شحن البطارية بواسطة المولد. شايف؟ دي كلها وظايف مش هحتاجها أصلاً علشان أتحكم في السيارة، لكنها مهمة جدًا للسيارة داخليًا. وبالتالي مش هتكون ضمن الـ Interfaces.
لاحظ إن مفهوم الـ Interfaces هنا يعني الواجهة النهائية المتاحة كـ Public للمستخدم، يعني الحاجات الضرورية اللي هيحتاجها علشان يعرف يعمل Control أو تحكم في الـ Object ده. وبالتالي برضو فيه وظايف مش ضرورية للتحكم، لكنها ضرورية لعملية التشغيل الداخلي بس.
وممكن ناخد مثال التلاجة مثلاً. لو قولتلك إن عندك الوظايف دي وعايز تصنّفها كـ Interface أو مش Interface، حاول مع نفسك كده بقى قبل ما تكمل:
- ضبط درجة الحرارة
- تشغيل الضاغط (Compressor)
- إيقاف أو تشغيل التلاجة
- اختيار وضع التبريد
- تدوير غاز التبريد
- الاستعلام عن حالة التلاجة
- إدارة تدفق الهواء داخل التلاجة
لو أخدت بالك، هنا فيه وظايف ضمن الـ Interface وفيه وظايف بتشتغل داخليًا بس ومش مطلوبة في عملية التحكم.
الوظايف الضرورية كـ Interfaces (Public):
- ضبط درجة الحرارة
- إيقاف أو تشغيل التلاجة
- اختيار وضع التبريد
- الاستعلام عن حالة التلاجة
الوظايف الغير ضرورية كـ (Private) Interfaces:
- تشغيل الضاغط (Compressor)
- تدوير غاز التبريد
- إدارة تدفق الهواء داخل التلاجة
يبقى لحد هنا كده المفروض نبقى فاهمين إني لازم أحدد الوظايف اللي هتكون ضمن الـ Interface وأخلّيها Public لأن دي ضرورية للاستخدام الخارجي. وبردو أحدد الوظايف اللي مش ضرورية كـ Interface وأخلّيها Private. والعملية دي أسهل ما يمكن زي ما إنت شوفت.
طيب، إيه ظروف الـ Attributes أو الداتا أو الـ State بتاعة الـ Object؟ لو أخدت بالك، في المنشور اللي فات قولنا إن لازم كل الـ Attributes أو الداتا أو الـ State بتاع الـ Object تبقى Private تمامًا، والتحكم فيها يبقى عن طريق Public Methods علشان يبقى عندي Control على الداتا.
#oop #ملخص
هو بيقولك إن التصميم الجيد للـ Class، أو المقبول على الأقل، لازم يمنع الوصول للوظايف اللي مش ضرورية للتحكم في الـ Object. يعني بكل بساطة كده، ما ينفعش تسيب كل حاجة Public كده وتقول أهي ماشية. الحقيقة إن ده تصميم سيء جدًا، ولازم تسمح الوصول بس للوظايف النهائية اللي بتتحكم في الـ Object. وممكن نضيف مثال من عندنا علشان نوضح الفكرة.
مثال السيارة: لو إنت كإنسان Object وعايز تسوق سيارة Object برضو، هتحتاج إيه من السيارة علشان تقدر تسوقها؟ هتحتاج فرامل، هتحتاج تشغّل السيارة، هتحتاج دواسة بنزين، هتحتاج تتحكم في الاتجاهات. يبقى لازم أوفّر Interfaces واضحة ومحددة للتحكم في السيارة دي، وبالتالي لازم الـ Methods دي كلها تبقى Public، صح؟
ملحوظة: الـ Interfaces في السياق ده مقصود بيها الوظايف العامة المسؤولة عن التحكم في الـ Object.
وبالتالي برضو ما ينفعش أخلّي وظايف تانية Public وهي المفروض تبقى Private لأنها مش ضرورية ولا مهمة للمستخدم النهائي. يعني مثلاً: نظام تبريد المحرك، عملية خلط الوقود والهواء في غرفة الاحتراق، نظام ضبط توقيت الصمامات، عملية شحن البطارية بواسطة المولد. شايف؟ دي كلها وظايف مش هحتاجها أصلاً علشان أتحكم في السيارة، لكنها مهمة جدًا للسيارة داخليًا. وبالتالي مش هتكون ضمن الـ Interfaces.
لاحظ إن مفهوم الـ Interfaces هنا يعني الواجهة النهائية المتاحة كـ Public للمستخدم، يعني الحاجات الضرورية اللي هيحتاجها علشان يعرف يعمل Control أو تحكم في الـ Object ده. وبالتالي برضو فيه وظايف مش ضرورية للتحكم، لكنها ضرورية لعملية التشغيل الداخلي بس.
وممكن ناخد مثال التلاجة مثلاً. لو قولتلك إن عندك الوظايف دي وعايز تصنّفها كـ Interface أو مش Interface، حاول مع نفسك كده بقى قبل ما تكمل:
- ضبط درجة الحرارة
- تشغيل الضاغط (Compressor)
- إيقاف أو تشغيل التلاجة
- اختيار وضع التبريد
- تدوير غاز التبريد
- الاستعلام عن حالة التلاجة
- إدارة تدفق الهواء داخل التلاجة
لو أخدت بالك، هنا فيه وظايف ضمن الـ Interface وفيه وظايف بتشتغل داخليًا بس ومش مطلوبة في عملية التحكم.
الوظايف الضرورية كـ Interfaces (Public):
- ضبط درجة الحرارة
- إيقاف أو تشغيل التلاجة
- اختيار وضع التبريد
- الاستعلام عن حالة التلاجة
الوظايف الغير ضرورية كـ (Private) Interfaces:
- تشغيل الضاغط (Compressor)
- تدوير غاز التبريد
- إدارة تدفق الهواء داخل التلاجة
يبقى لحد هنا كده المفروض نبقى فاهمين إني لازم أحدد الوظايف اللي هتكون ضمن الـ Interface وأخلّيها Public لأن دي ضرورية للاستخدام الخارجي. وبردو أحدد الوظايف اللي مش ضرورية كـ Interface وأخلّيها Private. والعملية دي أسهل ما يمكن زي ما إنت شوفت.
طيب، إيه ظروف الـ Attributes أو الداتا أو الـ State بتاعة الـ Object؟ لو أخدت بالك، في المنشور اللي فات قولنا إن لازم كل الـ Attributes أو الداتا أو الـ State بتاع الـ Object تبقى Private تمامًا، والتحكم فيها يبقى عن طريق Public Methods علشان يبقى عندي Control على الداتا.
#oop #ملخص
public class FlowChallenge {
public static void main(String[] args) {
int x = 0;
for (int i = 0; i < 5; i++) {
if (i % 2 == 0) {
continue;
}
switch (i) {
case 1:
x += 1;
break;
case 3:
x += 3;
default:
x += 2;
}
}
System.out.println(x);
}
}