أين تكمن صعوية الوراثة

اقتباس

أين وجدت الصعوبة عندما بدأت تعلم الوراثة و كيف تغلبت عليها؟

ماهي الوراثه ؟؟؟ :blink:

بسام العيساوي كتب:

ماهي الوراثه ؟؟؟ :blink:

قد يكون البعض قد تعود على المصطلح الانجليزي و هو Inheritance

http://ar.wikipedia.org/wiki/%D9%88%D8%B1%D8%A7%D8%AB%D8%A9_%28%D8%B9%D9%84%D9%88%D9%85_%D8%AD%D8%A7%D8%B3%D9%88%D8%A8%29

السلام عليكم :)

عجيب!!

دخلت وأنا أبحث عن الوراثة ولم أجد شيء يتحدث عنها..

وإنما وجدت إستطلاع عن رأي المجتمع حول التعليم بإستخدام الالعاب ثلاثية الابعاد 3D

هل الباحث متأكد أنه وضع الرابط الصحيح؟

أم أن هذا له علاقة ما مع الوراثة؟

الرجاء التوضيح حتى تمكن الاستفادة للجميع!

والسلام عليكم ورحمة الله وبركاته :)

AmeenSnw كتب:

السلام عليكم :)

عجيب!!

دخلت وأنا أبحث عن الوراثة ولم أجد شيء يتحدث عنها..

وإنما وجدت إستطلاع عن رأي المجتمع حول التعليم بإستخدام الالعاب ثلاثية الابعاد 3D

هل الباحث متأكد أنه وضع الرابط الصحيح؟

أم أن هذا له علاقة ما مع الوراثة؟

الرجاء التوضيح حتى تمكن الاستفادة للجميع!

والسلام عليكم ورحمة الله وبركاته :)

و عليكم السلام

صحيح المفترض أن أوضح الامر

حسناً ، الاستبيان هو لمعرفة رأي المجتمع حول التعليم بإستخدام الـ 3D بشكل عام و ليس حصراً على الوراثة أو البرمجة

هنا نريد أن نأخذ رأيكم كمبرمجين ربما تكونوا واجهتم صعوبة في فهم هذا الموضوع ، أين ترون صعوبة الموضوع؟

لأن هذا سوف يفيد في مساعدة طلاب البرمجة الجدد في فهم هذا الموضوع بطريقة أسهل

الوراثة Inheritance - يستطيع الكائن وراثة خصائص كائن معين والزيادة عليها دون أن يتأثر الكائن الأصلي. فقد يكون هناك مثلاً كائن اسمه مربع فيه خصائص الطول والعرض ويمكن للكائن مكعب أن يرث من المربع ويضيف عليه خصائص العمق والحجم.

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

هذا هو ملخص ما توصلت إليه في البحث من خلال موسوعة wikipedia...

هل هذا ما تقصده ؟ . .

أعتقد أن موضوعك شيق ويستحق أن تطرح علينا الأسئلة بصورة أوضح قليلا لنتشارك معك . .

براى المشكلة ليست باسلوب التدريس ولكن بتسلسل التدريس.

رائى الشخصى ان طريقة OOP First فى تعليم البرمجة لة عدة عيوب. اهمها انها تقدم لك الحلول قبل ان تعرف/تواجة المشكلة الى ادت لابتكار البرمجة الشيئية/الوراثة/ Design patterns . ارى الحل ان لا يتم التركيز على البرمجة الشيئية فى بداية البرمجة و التركيز على الجانب ال procdural لفترة من التعليم و من ثم الانتقال للبرمجة الشيئية.

اقتباس

الوراثة Inheritance - يستطيع الكائن وراثة خصائص كائن معين والزيادة عليها دون أن يتأثر الكائن الأصلي. فقد يكون هناك مثلاً كائن اسمه مربع فيه خصائص الطول والعرض ويمكن للكائن مكعب أن يرث من المربع ويضيف عليه خصائص العمق والحجم.

للأسف أخ ماجد, المكعب ليس مربعاً!

تستخدم الواراثة في غالب الأحيان من قبل المبرمجين بشكل خاطئ. يجب أن تكون هناك علاقة is-a لكي يكون تصميمك صحيحاً, و في غالب الأحيان يكون التصميم خاطئ. المكان الوحيد الذي رأيت فيه OOP makes sense هو في الـ GUI و الـ Simulation أما ما عدا ذلك فالمبرمجين يغردون خارج السرب.

ماجد الأسيوطي كتب:

الوراثة Inheritance - يستطيع الكائن وراثة خصائص كائن معين والزيادة عليها دون أن يتأثر الكائن الأصلي. فقد يكون هناك مثلاً كائن اسمه مربع فيه خصائص الطول والعرض ويمكن للكائن مكعب أن يرث من المربع ويضيف عليه خصائص العمق والحجم.

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

هذا هو ملخص ما توصلت إليه في البحث من خلال موسوعة wikipedia...

هل هذا ما تقصده ؟ . .

أعتقد أن موضوعك شيق ويستحق أن تطرح علينا الأسئلة بصورة أوضح قليلا لنتشارك معك . .

نعم هذا ما أعنيه ،

تخيل معي أنك تريد أن تنشىء صنف Class ليمثل سيارة عائلية ، ثم أردت إنشاء صنف Class أخر لسيارة رياضية ، فسوف تكتب غالب الكود مع وجود بعض الاضافات التي تمتاز بها السيارة الرياضية كزر البور أو المميزات الاخرى

تخيل أنك وجدت خطأ في الكود فأنك سوف تعدله في كلاسين ، لو أردت الاضافة فأنك سوف تضيفه مرتين

ماذا لو كان لديك ، خمسة سبعة عشرة عشرون كلاس ماذا ستفعل؟

الوراثة تقدم لك الحل بأن تقوم بإنشاء كلاس و تسميه "سيارة عامة" و فيه تكون الاشياء التي تحتاجها كل سيارة

و بعد ذلك تقوم بتوريث كلاس السيارة الرياضية منها ، كلاس السيارة الرياضية لن يحتوي إلا على الاشياء الاضافية فقط

أما الاشياء الرئيسية فهو تستطيع أن يستفيد من الكلاس الاب و الذي هو "السيارة العامة"

أفضل كتاب قرأته و تعلمت منه الوراثة هو الاكسير

http://www.kutub.info/library/book/218

apex كتب:

براى المشكلة ليست باسلوب التدريس ولكن بتسلسل التدريس.

رائى الشخصى ان طريقة OOP First فى تعليم البرمجة لة عدة عيوب. اهمها انها تقدم لك الحلول قبل ان تعرف/تواجة المشكلة الى ادت لابتكار البرمجة الشيئية/الوراثة/ Design patterns . ارى الحل ان لا يتم التركيز على البرمجة الشيئية فى بداية البرمجة و التركيز على الجانب ال procdural لفترة من التعليم و من ثم الانتقال للبرمجة الشيئية.

و أين ترى أي أجزاء الوراثة أصعب ، المفهوم ، طريقة الاستخدام ، syntax ،

syntax - قواعد الصياغة - هي الأصعب

فالمفهوم واضح للبرمجة الشيئية أو الكائنية Object Oriented Programming:

فهي تنحصر في الوراثة وتعدد الأشكال Inheritance & Polymorphism، وهما من التقنيات الفعّالة للتعامل مع البرمجيات المعقدّة:

• فالوراثة inheritance : هي شكل للبرامج software المعدّة للاستعمال مع الفئات classes الحديثة والتي أنشئت من فئات موجودة مسبقاً وأخذت عنها خصائصها وسلوكها وأضافت إليها القدرات التي نحتاج إليها في هذه الفئة الجديدة.

فالوراثة ؟! تعني بالضبط ما الذي تم وراثته و كيف يمكن التعديل عليه وما الذي لا يمكن وراثته -يتضح ذلك بالأمثلة-. هذه الخاصية توفر الكثير من الوقت للمبرمج وتقطع عنه أشواطاً في تطوير برنامجه.

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

فالفئات الجديدة -تسمى فئة فرعية subclass- ترث صفات الفئات التي أُنتجت وتكونت منها -تسمى الفئة الأم superclass- كما يرث الطفل جينات أبويه. وهذه الفئة الجديدة والتي تعتبر subclass، من الممكن أن تكون superclass لفئات جديدة أخرى ينشئها المبرمج. وهكذا تمتد لدينا سلسلة من الوراثة بين الفئات extends، يحكمها قانون "الوراثة المفردة Single Inheritance" حيث ينص هذا القانون على:

تنشأ أي فئة فرعية من فئة أم واحدة،

فالـOOP تقوم باحتواء البيانات (Data (attributes والطرق (Methods (behavior في حزمة package تحت مسمي"كائنات Objects"؛ حيث ترتبط ببعضها ارتباط وثيق وايضا تتميّز بخاصية التخفي Information Hiding بمعني بإمكان الكائنات الاتصال والتعامل مع بعضها البعض مع عدم معرفة كيفيه تكون الاخري !

وكمثال علي ذلك نحن نعرف كيف نقود السيارات بكفاءة عالية دون معرفة التفاصيل الميكانيكية لها . تسمى هذه الخاصية في البرمجة بـAbstraction أي تجريد البيانات.

حتى تتعلم الوراثة جيدا وتفهمها يجب الإجابة على السؤال التالي

ما هي المشاكل التي واجهت المطورين حتى جاؤوا بمفهوم الوراثة

اما فقط حفظ الكود وطرحه فلن يعلمك أي شيء اللهم الحفظ

ولهذا المطولب الاول فهم ماهي غاية الظاهرة وماالهدف منها وما الدافع لإكتشافها كل هذا سيساعدك على فهم الوراثة بشكل جيد لا بشكل حفظي

bilal2005 كتب:

حتى تتعلم الوراثة جيدا وتفهمها يجب الإجابة على السؤال التالي

ما هي المشاكل التي واجهت المطورين حتى جاؤوا بمفهوم الوراثة

اما فقط حفظ الكود وطرحه فلن يعلمك أي شيء اللهم الحفظ

ولهذا المطولب الاول فهم ماهي غاية الظاهرة وماالهدف منها وما الدافع لإكتشافها كل هذا سيساعدك على فهم الوراثة بشكل جيد لا بشكل حفظي

اقتباس

فالمفهوم واضح للبرمجة الشيئية أو الكائنية Object Oriented Programming:

فهي تنحصر في الوراثة وتعدد الأشكال Inheritance & Polymorphism، وهما من التقنيات الفعّالة للتعامل مع البرمجيات المعقدّة:

• فالوراثة inheritance : هي شكل للبرامج software المعدّة للاستعمال مع الفئات classes الحديثة والتي أنشئت من فئات موجودة مسبقاً وأخذت عنها خصائصها وسلوكها وأضافت إليها القدرات التي نحتاج إليها في هذه الفئة الجديدة.

فالوراثة ؟! تعني بالضبط ما الذي تم وراثته و كيف يمكن التعديل عليه وما الذي لا يمكن وراثته -يتضح ذلك بالأمثلة-. هذه الخاصية توفر الكثير من الوقت للمبرمج وتقطع عنه أشواطاً في تطوير برنامجه.

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

فالفئات الجديدة -تسمى فئة فرعية subclass- ترث صفات الفئات التي أُنتجت وتكونت منها -تسمى الفئة الأم superclass- كما يرث الطفل جينات أبويه. وهذه الفئة الجديدة والتي تعتبر subclass، من الممكن أن تكون superclass لفئات جديدة أخرى ينشئها المبرمج. وهكذا تمتد لدينا سلسلة من الوراثة بين الفئات extends، يحكمها قانون "الوراثة المفردة Single Inheritance" حيث ينص هذا القانون على:

تنشأ أي فئة فرعية من فئة أم واحدة،

فالـOOP تقوم باحتواء البيانات (Data (attributes والطرق (Methods (behavior في حزمة package تحت مسمي"كائنات Objects"؛ حيث ترتبط ببعضها ارتباط وثيق وايضا تتميّز بخاصية التخفي Information Hiding بمعني بإمكان الكائنات الاتصال والتعامل مع بعضها البعض مع عدم معرفة كيفيه تكون الاخري !

وكمثال علي ذلك نحن نعرف كيف نقود السيارات بكفاءة عالية دون معرفة التفاصيل الميكانيكية لها . تسمى هذه الخاصية في البرمجة بـAbstraction أي تجريد البيانات.

بارك الله فيكم ، أفدتم

السلام عليكم..

بما أن الموضوع تحول لنقاش شيق، اسمحوا لي رجاءً أن أشارك بالقليل..

apex كتب:

براى المشكلة ليست باسلوب التدريس ولكن بتسلسل التدريس.

رائى الشخصى ان طريقة OOP First فى تعليم البرمجة لة عدة عيوب. اهمها انها تقدم لك الحلول قبل ان تعرف/تواجة المشكلة الى ادت لابتكار البرمجة الشيئية/الوراثة/ Design patterns . ارى الحل ان لا يتم التركيز على البرمجة الشيئية فى بداية البرمجة و التركيز على الجانب ال procdural لفترة من التعليم و من ثم الانتقال للبرمجة الشيئية.

طريقة OOP First قد تكون بالفعل خاطئة.. لكن ما رأيك في Procedural OOP Programming، بمعنى ما تجده عادةً من كود تعريفي بلغة كـRuby أو Python.. هو OOP، لكن مباشرة في الملف، بلا إنشاء classes و لا شيء معقد - لا داع له في وقت كهذا.. لكن في نفس الوقت تحصل على الإمكانيات الكبيرة، و تتعلم الشكل "الجميل" للكود (رأي شخصي ليس إلا)!

Khaled.Alshaya كتب:

للأسف أخ ماجد, المكعب ليس مربعاً!

تستخدم الواراثة في غالب الأحيان من قبل المبرمجين بشكل خاطئ. يجب أن تكون هناك علاقة is-a لكي يكون تصميمك صحيحاً, و في غالب الأحيان يكون التصميم خاطئ. المكان الوحيد الذي رأيت فيه OOP makes sense هو في الـ GUI و الـ Simulation أما ما عدا ذلك فالمبرمجين يغردون خارج السرب.

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

تعديل: كلامي هذا لا يعني أبدًا أني من مؤيدي وراثة المكعب من المربع، أو أني أفعل شيئًا كهذا أبدًا! الوراثة - أغلبها - تكون فقط في الاستخدام العملي لإطلاق نوع مطور أو مخصص أكثر يؤدي نفس الوظيفة.

شكرًا..

اقتباس

طريقة OOP First قد تكون بالفعل خاطئة.. لكن ما رأيك في Procedural OOP Programming، بمعنى ما تجده عادةً من كود تعريفي بلغة كـRuby أو Python.. هو OOP، لكن مباشرة في الملف، بلا إنشاء classes و لا شيء معقد - لا داع له في وقت كهذا.. لكن في نفس الوقت تحصل على الإمكانيات الكبيرة، و تتعلم الشكل "الجميل" للكود (رأي شخصي ليس إلا)!

متفقين, انا فقط طلبت "عدم التركيز". ولكن ما لاحظتة من تجربتى فى الكلية عندما بداو بلغة OOP. ان الامر كان مبهم للكثير و كثير كانوا يظنوا ان البرمجة بدون برمجة شيئية غير ممكن و ان ادواتها هى الوسيلة الوحيدة(او على الافضل) للبرمجة.

Khaled.Alshaya كتب:

للأسف أخ ماجد, المكعب ليس مربعاً!

تستخدم الواراثة في غالب الأحيان من قبل المبرمجين بشكل خاطئ. يجب أن تكون هناك علاقة is-a لكي يكون تصميمك صحيحاً, و في غالب الأحيان يكون التصميم خاطئ. المكان الوحيد الذي رأيت فيه OOP makes sense هو في الـ GUI و الـ Simulation أما ما عدا ذلك فالمبرمجين يغردون خارج السرب.

معك حق ،

أذكر أننا كنا ندرس أحد الأمثلة و كان يعطيني مثال : دائرة ترث من نقطة :-) ، لا أعرف حتى الآن ما علاقة هذا بذاك . تصميم engine او framework ، يجعل المبرمج يدرك أهمية الوراثة و غيرها من مفاهيم oop . اما مجرد بريمج فيه "موظف " يرث من person أو مربع يرث من مكعب ، فلا معنى له و لا يعطي للطالب الدليل الكافي ليقتنع بأهمية الوراثة و مفاهيم oop بشكل عام .

تجاربي الشخصية ، من النادر أن أحتاج إلى وراثة بدون polymorphism ، يعني وراثة لوحدها قد لا تكفي في أغلب الأحيان ..

==

ملاحظة : تم حذف الرابط ، المفروض ليس هذا مكانه : ) .

Khaled.Alshaya كتب:

للأسف أخ ماجد, المكعب ليس مربعاً!

تستخدم الواراثة في غالب الأحيان من قبل المبرمجين بشكل خاطئ. يجب أن تكون هناك علاقة is-a لكي يكون تصميمك صحيحاً, و في غالب الأحيان يكون التصميم خاطئ. المكان الوحيد الذي رأيت فيه OOP makes sense هو في الـ GUI و الـ Simulation أما ما عدا ذلك فالمبرمجين يغردون خارج السرب.

sitesmaker كتب:

السلام عليكم..

بما أن الموضوع تحول لنقاش شيق، اسمحوا لي رجاءً أن أشارك بالقليل..

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

شكرا لكما . . حوار شيق والاختلاف في الآراء لا يفسد للـ OOP قضية . .

اقتباس

تجاربي الشخصية ، من النادر أن أحتاج إلى وراثة بدون polymorphism ، يعني وراثة لوحدها قد لا تكفي في أغلب الأحيان ..

أتفق معك تماماً في هذا, أصلاً الوراثة لم تستحدث إلا للـ Polymorphism الذي هو قلب OOP و ليست الوراثة بحد ذاتها كـ Code Reuse.

من مشاكل الوراثة هي أن الفئة الوارثة (Child Class) تصبح مرتبطة بشدة (Tightly Coupled) بالفئة الموروث منها (Parent Class) و هنا تتعقد الأمور, لأنك تعتمد على أجزاء من الكود التي قد لا تتحكم في طريقة كتابتها أو لا تستطيع تغييرها بالذات اذا كانت هذه الأجزاء في غير معرفة على أنها virtual.

المشكلة أيضاً تتمثل في عدم قدرتك على تغيير سلوك (Behavior) الObject في الRuntime و هذا لأنك لن تستطيع أن ترث من أب جديد فجأة و لهذا أحبذ اللجوء الى الComposition أو التركيب عن طريق أن تبني الObject من مجموعة Objects أصغر كل هذه الObjects مستقل بذاته و يتفقون بينهم على واجهة interface محدد مما يمكنك من تغيير شكل الObject المركب ببساطة في الRun time عن طريق تغيير الobjects الأصغر التي يتركب منها. كما أنه يعطيك فرصة لاعادة استخدام هذه الObjects الاصغر في أشياء أخرى.

اقتباس

من مشاكل الوراثة هي أن الفئة الوارثة (Child Class) تصبح مرتبطة بشدة (Tightly Coupled) بالفئة الموروث منها (Parent Class) و هنا تتعقد الأمور, لأنك تعتمد على أجزاء من الكود التي قد لا تتحكم في طريقة كتابتها أو لا تستطيع تغييرها بالذات اذا كانت هذه الأجزاء في غير معرفة على أنها virtual.

هنا يبقى دائما في ما تستحدم الوراثة وما الهدف من إستخدماها في مشروعك بالاساس

تحديد هذه الامور سيكون لها دور كبير في تجبن الكثير من المشاكل

في البرمجة لايتم إعتماد تقنية حتى يكون هناك حاجة ملحة لإستخدامها وهنا سيتم تجنب الكثير من المشاكل

والخطا الذذي نقع فيه هو انه لا تكون لنا بعيدة للمشروع نريد ان نكمله بسرعة من غير النظر هل سيكون هناك تطوير له من بعد ما الهدف بعد إكمال المشروع .................

كل هذا سيساعد في بناء الدوال والطريقة التي يتم بنائها

السلام عليكم..

من ضمن ما يمكن قوله بهذا الخصوص، هو مميزات Ruby هنا (و كلمة مميزات، لا تعني أن تلك الأشياء هي السليمة بالضرورة!). فمثلًا يمكن تعريف دوال خاصة بالـObject، بل لا يمكن غير ذلك، لأن الـClass كذلك عبارة عن Object (ترث من الفئة Class)، و بالتالي تعريف دالة للفئة أو للكائن هو تعريف دالة خاصة بكائن، و يكون الكائن منفصل عن الفئة إلى حد كبير، فيمكنني أن أرث من الفئة Triangle وأقوم بمسح كل الدوال الخاصة بتلك الفئة من الكائن فسحب، وأضيف الدوال التي أريد، فيصبح دائرة، لكنه في النهاية من الفئة Triangle! ((لهذا علاقة بالـDuck Typing)) بسبب هذا لا يعود هناك ارتباط قوي بين الفئة الوارثة، والفئة الأب، ولا حتى بين الكائن و فئته! بل ويمكن إعادة "فتح" فئة و التعديل عليها، مما يؤثر على أي كائن متعلق بنفس الفئة، بعد التعديل - لا قبله!

ما قصدته، أنه من الممكن "تغيير سلوك (Behavior) الObject في الRuntime" فجأة، ولكن ذلك غير واسع النطاق، و - في النهاية - غير محبذ استخدامه بغير سبب منطقي (لمنع "التوهان"!).

اقتباس

المشكلة أيضاً تتمثل في عدم قدرتك على تغيير سلوك (Behavior) الObject في الRuntime و هذا لأنك لن تستطيع أن ترث من أب جديد فجأة و لهذا أحبذ اللجوء الى الComposition أو التركيب عن طريق أن تبني الObject من مجموعة Objects أصغر كل هذه الObjects مستقل بذاته و يتفقون بينهم على واجهة interface محدد مما يمكنك من تغيير شكل الObject المركب ببساطة في الRun time عن طريق تغيير الobjects الأصغر التي يتركب منها. كما أنه يعطيك فرصة لاعادة استخدام هذه الObjects الاصغر في أشياء أخرى.

Strategy Pattern ?

فيه مفاهيم جديدة اليومين هذي

Traits

Mixins

موجودة في Ruby و Scala

يوجد كذلك Typeclasses في Haskell و Scala

لا أعرف عنها الكثير، بودي لو أحد يعرف هذي المفاهيم يوضحها لنا

اضافة:

محاضرة: الـ Typeclass كبديل للوراثة،

__Unknown كتب:

Strategy Pattern ?

Strategy Pattern واحد من الأنماط التي تعتمد على التركيب Composition لكن المبدأ عموماً يمكن استخدامه حتى لو لم تستخدم الStrategy Pattern بحذافيره

اقتباس

Strategy Pattern واحد من الأنماط التي تعتمد على التركيب Composition لكن المبدأ عموماً يمكن استخدامه حتى لو لم تستخدم الStrategy Pattern بحذافيره

أينعم أتفق معك ...