اول منشور


هنبدأ نتكلم عن كتاب 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 وهنتكلم عن مفهوم الـ 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 #ملخص

🍃اللهم صلِّ وسلم على نبينا محمد.
-الكهف و الاكثار من الصلاه على النبي-💗

هنكمل كلامنا مع الفصل الأول من كتاب _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 #ملخص

احترس كثيراً من المهندسين👌👌

إن شاء الله هنكمل مع الباب الأول من كتاب Object-Oriented Thought Process وهنتكلم عن الـInheritance بشكل مبدئي.

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

بس مع الـOO الموضوع مختلف شوية لأنك مش بس بتعيد استخدام الكود، ولكنك بتبني علاقة (Relationships) ما بين الكلاسات، والموضوع ده بيخلي التصميم العام للبرنامج أفضل بكتير. وعملية الـRelationships دي بنعملها بالـInheritance.

تعالَ ناخد مثال علشان نوضح الفكرة أكتر. لو عندك كائن (Dog) وعايز تحفّظ بصفة زي مثلًا "لون العيون"، وعندك كائن (Cat) وعايز تحفّظ برضو بصفة "لون العيون"، في الحالة دي لو أنت ماشي صح هتعمل كائن عام أكتر وتسميه Mammal (ثدييات) أو ممكن تسميه (Animal) وتحفّظ الصفة المشتركة دي فيه وتعمل وراثة من الـMammal للـDog ومن الـMammal للـCat.

وهنا بقى لو قابلك أي صفة أو سلوك مشترك في المستقبل زي وظيفة الـEat، في الحالة دي هتروح تحطها بس في الـMammal، وبالتالي بما إن فيه علاقة (Relationship) ما بين الـMammal والـCat والـDog، فبالتالي الـCat والـDog هيبقى ليهم Access تلقائي للوظيفة دي.

معلومة مهمة جدًا: في عملية الوراثة (Inheritance) مش بيحصل عملية Copy لمكونات الأب (Superclass) تتنقل للابن (Subclass)، ولكنها علاقة (Relationship). يعني طول ما فيه علاقة (Relationship) ما بين كلاس الأب وكلاس الابن، في الحالة دي كلاس الابن يقدر يوصل لمحتويات كلاس الأب. خلّي بالك أوي لأن في ناس كتير بتبقى فاكرة إنها Copy لمكونات الأب (Superclass) داخل الابن (Subclass). كلمة (Relationship) بشوفها أوضح بكتير من كلمة (Inheritance) في سياق التعريف بالمفهوم، ولكن في السياق العام بنقول (Inheritance).

علاقة الـInheritance بنقول عليها IS-A Relationship، يعني لو قولتلك أنا عندي كائن (BMW) وكائن (Toyota) وكائن (Ford)، كل دول ينفع نقول عليهم IS-A Car، صح؟ يعني كلهم مشتركين في إنهم سيارات. وبالتالي دايمًا هيبقى فيه صفات مشتركة بينهم. والحل هنا بقى إني أعمل Car Class وأحط فيه الحاجات المشتركة وأخلّي الـBMW والـToyota والـFord تورث من الكلاس ده.

خلينا ناخد مثال عن الحيوانات بدل السيارات. لنفترض إن عندنا حيوانات زي كلب (Dog)، قط (Cat)، وطائر (Bird)، وكلهم حيوانات، يعني كلهم IS-A Animal. كل الحيوانات دي بتتشارك في صفات وسلوكيات مشتركة زي إنها بتاكل، بتتحرك، وبيكون عندها اسم أو عمر. بس كل نوع حيوان عنده حاجات خاصة بيه. وبالتالي هنعمل Animal Class يكون فيه الحاجات المشتركة بينهم كلهم ونطبّق علاقة الوراثة (Inheritance).

أهم حاجة دلوقتي تبقى فاهم ليه Inheritance وليه بنستخدمه وتبقى فاهم مصطلح Relationship ما بين الـBase Class والـChild Class.

#oop #ملخص

إن شاء الله هنكمل مع الباب الأول من كتاب _Object-Oriented Thought Process_، وهنتكلّم عن الـ Polymorphism بشكل مبدئي.

كلمة Polymorphism دي كلمة يونانية، معناها الحرفي "أشكال كتير". الكاتب بيقول إن المفهوم ده مرتبط جدًا بالوراثة (Inheritance)، بس في كتير من الأحيان بيتم ذكره لوحده. والكلام ده مظبوط 100%! لو حاولت تفصل الـ Polymorphism عن الـ Inheritance، هتتلخبط وهتحس إن فيه حاجة غلط أو مش مفهومة.

تعالى نأخد تعريف معين ونحاول نبسطه أكتر: التعددية (Polymorphism) تعني إن الكائنات من أنواع مختلفة يمكن تتعامل معاهم بطريقة موحدة لو كانوا بيشاركو في واجهة مشتركة أو كلاس أساسي.

شايف التعريف ده؟ وراه أقوى وأجمد حاجة حرفيًا في الـ OOP! ميكس عجيب جدًا تقدر توصلّه لما تطبق الـ Inheritance صح.

معلومة مهمة الـ Polymorphism هو نتيجة بتوصّلها لما تنفذ الوراثة (Inheritance) بشكل سليم، وبالتالي بتلاقي نفسك قادر تطبق الـ Polymorphism بكل بساطة.

الحقيقة، إحنا هنتكلّم عن مثال كان موجود في الكتاب، وهو مثال الأشكال الهندسية، زي المثلث، المربع، والمستطيل. لو عايزين نطبق الوراثة صح، لازم نسأل نفسنا: المثلث والمربع والمستطيل دول عبارة عن إيه؟ أو بمعنى تاني، علاقة الـ IS-A اللي اتكلمنا عليها في المنشور اللي فات؟ لو فكرت شوية، هتلاقيهم كلهم عبارة عن Shapes، صح (IS-A Shape). المربع Is A Shape المثلث Is A Shape الدائرة Is A Shape طيب، حلو، تعالى نشوف إحنا في سياق البرنامج بتاعنا عايزين نعمل إيه بالأشكال دي؟ وليّكن عايزين نعمل برنامج رسام بيرسم الأشكال دي، وكمان يحسبلي المحيط والمساحة بتاعة كل شكل بنرسمه.

وهنا هتلاحظ حاجة حلوة، وهي إني هعمل كلاس اسمه Shape، ماشي؟ وبعدين هسأل نفسي: إيه الحاجات اللي عايزها تتنفذ في كل الكلاسات دي؟ وليّكن الرسم، وحساب المحيط، وحساب المساحة لكل شكل.

يبقى دلوقتي هيكون عندي 3 وظايف مشتركة بين الأشكال كلها: Draw، CalcArea، وCalcPerimeter. حلو؟ بس أنت ممكن تقولي: "بس طريقة الرسم هنا مختلفة عن هنا، وكمان طريقة حساب المساحة للشكل ده مختلفة عن الشكل ده وده!" وبالتالي أنت ممكن تقولي إن المشترك الوحيد هو اسم الوظيفة بس، ولكن التنفيذ (Implementation) مختلف بينهم كلهم، يعني مفيش حاجة مشتركة علشان أروح أحطها في الـ Base Class.

هنا بقى مربط الفرس، وركز أوي. أه، كلهم بيحسبوا الـ Area مثلاً، بس طريقة حساب الـ Area هنا مختلفة عن هنا، وبالتالي مش هينفع نكتبها في الـ Base Class، صح؟ كلامك مظبوط، طالما الـ Implementation مختلف بينهم كلهم، إزاي هروح أضيف Implementation في الـ Base Class؟ ما هي كده كده مش مشتركة بينهم!

بس ينفع نعمل Interface لتعريف الـ Draw يكون فاضي بدون Implementation، صح؟ يعني بالشكل ده:

class Shape {
public virtual void Draw();
}

ياسلام، طيب ليه أصلاً أضيف Interface فاضي من غير Implementation؟ ما أنا كده كده هروح أبني الـ Method على طول في كل Subclass وأريح دماغي؟

أول سبب لوجود الـ Interface الفاضي ده هو إنه بيجبر أي Subclass إنها تقدم Implementation للوظيفة دي، وبنقول على الموضوع ده عقد (Contract). لو معملتش Implementation، هيجيلك Compile-time Error. يعني الـ Base Class بكل بساطة بيقولك: "أنا عندي وظيفة اسمها Draw، لازم تنفذها لو عايز تعمل Inheritance من عندي."

هنا برده ممكن تسأل نفسك سؤال تاني وتقول: "أنا استفدت إيه من عملية الـ Contract دي؟ وليه أصلاً أروح ألف وأعمل الحوارات دي كلها، برضو ما أنا كده كده هروح أنفذ الـ Implementation بتاع كل Subclass من الأساس؟ يعني ليه الخطوات الزيادة دي؟"

هنا بقى الـ Polymorphism! طبعاً أنت دلوقتي بتقولي يعني استفدت إيه من المعلومة دي؟ وفين الـ Polymorphism ده علشان مش شايفه؟ طالما أجبرت كل الـ Child Classes ينفذوا نفس الوظايف الموجودة في الـ Base Class، فأنا أقدر أتحكم في كل الأشكال دي بطريقة موحدة وثابتة، على الرغم من اختلاف الشكل. بحيث كل شكل يستجيب للرسالة أو للأمر على حسب نوعه الفعلي.

يعني لو عملت متغير من نوع Shape في الحالة دي، أقدر أخزن فيه أي Subclass من نفس النوع، زي كده:

Shape sh = new Circle(); sh.Draw();

لو أخدت بالك، المتغير من نوع Shape، بس النوع الفعلي بعد علامة الـ = هو من نوع Circle. والموضوع ده بنقول عليه Upcasting، ممكن تسيّرش عليه. لما أجي أشغل وظيفة الـ Draw، هتعمل إيه بالظبط؟ هتروح ترسم دايرة، صح.

بس لو غيرت محتوى متغير الـ sh من Circle لـ Square، كده:

sh = new Square(); sh.Draw();

في الحالة دي، هيروح يرسم مربع. هنا بقى كل Object بدأ يستجيب لوظيفة الـ Draw على حسب نوعه الفعلي.

ولو عملت مصفوفة من نوع Shape، كده:

Shape[] sh = {new Square(), new Circle(), new Triangle()};

لو عملت تكرار (iteration) على الـ Array دي وشغلت وظيفة الـ Draw مع كل Object، بالتالي وظيفة الـ Draw هتطبع في أول مرة مربع، ثم دايرة، ثم مثلث. لو أخدت بالك، ده بالظبط هو الـ Polymorphism.

ليه بقى لازم نضيف Interface فاضي حتى لو من غير Implementation؟ الإجابة بكل بساطة: عشان نعرف نطبق الـ Polymorphism ونعمل توحيد للتعامل مع كل الـ Objects اللي وارثة من الـ Base Class من خلال الـ Sub Class.


#oop #ملخص