هل يسمح فى لغه السى شارب بالوراثه المتعدده Multiple Inheritance ؟ لايسمح بالسى شارب بالوراثه المتعدده من اكثر من فئه ــــــــــــــــــــــــــــــــــــــــــــــــ ـــــــــــــــــــــــــ ــــــــــــــــــــــــــــــــــــــــــــــ ما هو البديل لمفهوم الوراثة المتعدده فى السى شارب ؟ البديل هو ان نقوم باستخدام الواجهات IInterface ــــــــــــــــــــــــــــــــــــــــــــــــ ـــــــــــــــــــــــــ ــــــــــــــــــــــــــــــــــــــــــــــ هل يمكن استنساخ كائتنات من الواجهات ؟ #علل_جوابك لا يمكن استنساخ كائنات من الواجهات لانها تحتوى فقط على اعلان عن الوظائف والخصائص التى ستحتاجها الفئه ولا يوجد بها اى كود
كان من الأفضل يا اخي ان تقوم بإنشاء واجهتين اثتنين او 3 او 4 و كلاس واحد يرث منهم حتى نفهم جيدا الدرس أما ما فعلته انت حاليا يمكننا ان نقوم به بالوراثة العادية فقط .وتحياتي اخي الفاضل
١ لا يسمح للc# بالوراثة المتعددة والبديل هو الinterface. ٣ لا يمكن استنساخ كائنات من الواجهات لانها مجردة وفقط لتنظيم العمل واجبار المبرمج على اتباع هيكل معين.
namespace Interface { interface Quadrangle { int longeur { get; set; } int largeur { get; set; } float Surface(); } class Rectangle : Quadrangle { private int longeur; private int largeur; // constructeur public Rectangle(int lon, int lar) { this.longeur = lon; this.largeur = lar; } /* la modification des proprieté et la methode surface de l'interface dans la class rectangle */ int Quadrangle.largeur { get { return this.largeur; } set { this.largeur = value; } } int Quadrangle.longeur { get { return this.longeur; } set { this.longeur = value; } } float Quadrangle.Surface() { return this.largeur * this.longeur; } } class Program { static void Main(string[] args) { Quadrangle Qua1 = new Rectangle(50, 20); Console.WriteLine(" La surface est : {0}",Qua1.Surface()); Console.ReadKey();
بشكل عام ، يذهب الحكم إلى شيء مثل هذا: يصف الوراثة علاقة. يصف تطبيق الواجهة علاقة يمكن تنفيذها. لوضع هذا في مصطلحات أكثر واقعية إلى حد ما ، دعونا ننظر إلى مثال. فئة System.Drawing.Bitmap هي صورة (وعلى هذا النحو ، فإنها ترث من فئة الصورة) ، ولكنها أيضًا يمكن التخلص منها ، لذا فهي تنفذ واجهة IDisposable. كما أنه يمكن إجراء تسلسل ، بحيث يتم تنفيذه من واجهة ISerializable. لكن من الناحية العملية ، غالبًا ما تستخدم الواجهات لمحاكاة الوراثة المتعددة في C #. إذا احتجت فئة المعالج إلى ورثها من شيء مثل System.ComponentModel.Component ، فليس لديك خيار سوى تطبيق واجهة IProcessor. الحقيقة هي أن كلاً من الواجهات والطبقة الأساسية المجردة توفر عقدًا يحدد ما يمكن لفئة معينة القيام به. إنها خرافة شائعة مفادها أن الواجهات ضرورية لإعلان هذا العقد ، لكن هذا غير صحيح. أكبر ميزة في ذهني هي أن الطبقات الأساسية المجردة تسمح لك بتوفير وظيفة افتراضية للفئات الفرعية. ولكن إذا لم تكن هناك وظيفة افتراضية منطقية ، فلا يوجد ما يمنعك من وضع علامة على الطريقة نفسها على أنها مجردة ، مما يتطلب أن تنفذ الفئات المشتقة هذه العملية بنفسها ، مثلما إذا كانت ستقوم بتنفيذ واجهة. للحصول على إجابات لأسئلة مثل هذا ، غالبًا ما أنتقل إلى إرشادات تصميم .NET Framework ، والتي يجب أن نقولها عن الاختيار بين الفئات والواجهات: بشكل عام ، الطبقات هي البنية المفضلة لفضح التجريدات. العيب الرئيسي للواجهات هو أنها أقل مرونة بكثير من الفئات عندما يتعلق الأمر بالسماح بتطوير واجهات برمجة التطبيقات. بمجرد شحن واجهة ، يتم إصلاح مجموعة أعضائها إلى الأبد. أي إضافات إلى الواجهة ستقطع الأنواع الموجودة التي تنفذ الواجهة. يقدم الفصل مرونة أكثر. يمكنك إضافة أعضاء إلى الفئات التي قمت بشحنها بالفعل. طالما أن الطريقة ليست مجردة (أي ، طالما توفر تطبيقًا افتراضيًا للطريقة) ، تستمر أي فئات مشتقة موجودة في العمل دون تغيير. [. . . ] إحدى الحجج الأكثر شيوعًا لصالح الواجهات هي أنها تسمح بفصل العقد عن التنفيذ. ومع ذلك ، تفترض الوسيطة بشكل غير صحيح أنه لا يمكنك فصل العقود عن التنفيذ باستخدام الفئات. تعد الطبقات المجردة الموجودة في مجموعة منفصلة عن تطبيقاتها الملموسة طريقة رائعة لتحقيق هذا الفصل. توصياتهم العامة هي كما يلي: هل تفضل تحديد الطبقات على واجهات. لا تستخدم فئات مجردة بدلاً من واجهات لفصل العقد من التطبيقات. فئات الملخصات ، إذا تم تعريفها بشكل صحيح ، تسمح لنفس الدرجة من الفصل بين العقد والتنفيذ. حدد واجهة إذا كنت بحاجة إلى تقديم تسلسل هرمي متعدد الأشكال لأنواع القيم. النظر في تحديد واجهات لتحقيق تأثير مماثل لذلك من الميراث متعددة. يعبر كريس أندرسون عن اتفاق خاص مع هذه العقيدة الأخيرة ، بحجة أن: تعمل أنواع الخلاصات بشكل أفضل كثيرًا ، وتتيح إمكانية التمدد في المستقبل ، لكنها تحرق أيضًا نوعك الأساسي الوحيد. تكون الواجهات مناسبة عندما تحدد حقًا عقدًا بين كائنين ثابتين بمرور الوقت. تعد أنواع القواعد المجردة أفضل لتحديد قاعدة مشتركة لمجموعة من الأنواع.
هل يسمح فى لغه السى شارب بالوراثه المتعدده Multiple Inheritance ؟
لايسمح بالسى شارب بالوراثه المتعدده من اكثر من فئه
ــــــــــــــــــــــــــــــــــــــــــــــــ ـــــــــــــــــــــــــ ــــــــــــــــــــــــــــــــــــــــــــــ
ما هو البديل لمفهوم الوراثة المتعدده فى السى شارب ؟
البديل هو ان نقوم باستخدام الواجهات IInterface
ــــــــــــــــــــــــــــــــــــــــــــــــ ـــــــــــــــــــــــــ ــــــــــــــــــــــــــــــــــــــــــــــ
هل يمكن استنساخ كائتنات من الواجهات ؟ #علل_جوابك
لا يمكن استنساخ كائنات من الواجهات لانها تحتوى فقط على اعلان عن الوظائف والخصائص التى ستحتاجها الفئه ولا يوجد بها اى كود
interface
كان من الأفضل يا اخي ان تقوم بإنشاء واجهتين اثتنين او 3 او 4 و كلاس واحد يرث منهم حتى نفهم جيدا الدرس أما ما فعلته انت حاليا يمكننا ان نقوم به بالوراثة العادية فقط .وتحياتي اخي الفاضل
ابداعك بلا حدود دام لك البشر والفرح
١
لا يسمح للc# بالوراثة المتعددة والبديل هو الinterface.
٣
لا يمكن استنساخ كائنات من الواجهات لانها مجردة وفقط لتنظيم العمل واجبار المبرمج على اتباع هيكل معين.
السلام عليكم ولرحمة الله وبركاته بارك الله فيك اخي العزيز ونتمنى لك كل التوفيق ونتمى اذا في محاضرات بخصوص الماتلاب
في الشبكات العصبية وشكرا
جزاكم الله خيرا.
بارك الله فيك و جزاك الجنة..
جزاكم الله خيرا
بارك الله بيك
بارك الله بك على هذه الدروس
الله يجزيك الخير ويبارك فيك
شكرا جزيلا
لما عم اعمل كلاس ابن عم يحطلي خطأ انو ما فيني اورث من quadrangle شي وعم يضل مخططلي تحتا احمر
نفس المشكله عندي
استاذ خالد كيف نرث من عدة واجهات لفئة واحدة؟
الفئة التي سترث نضع بعد : ثم إسم الواجهة الأولى , الواجهة الثانية
مثال
Programmer : Person1 , Person2
{
//Codes
}
Rectangle لماذا في كلاس
كتبنا
private int width;
private int height;
اذا حدا بيعرف يفيدنا
^_^
لماذا أرا كل شيئ في جافا موجود ب سي شارب لهذه الدرجة مايكروسوفة لا تستطيع أن تطور شيئ وحدها بدون سرفة
لأن مايكروسوفت طورتها فس الأساس لمحاربة الجافا
namespace Interface
{
interface Quadrangle
{
int longeur { get; set; }
int largeur { get; set; }
float Surface();
}
class Rectangle : Quadrangle
{
private int longeur;
private int largeur;
// constructeur
public Rectangle(int lon, int lar)
{
this.longeur = lon;
this.largeur = lar;
}
/* la modification des proprieté et la methode surface de l'interface dans la class rectangle */
int Quadrangle.largeur
{
get { return this.largeur; }
set { this.largeur = value; }
}
int Quadrangle.longeur
{
get { return this.longeur; }
set { this.longeur = value; }
}
float Quadrangle.Surface()
{
return this.largeur * this.longeur;
}
}
class Program
{
static void Main(string[] args)
{
Quadrangle Qua1 = new Rectangle(50, 20);
Console.WriteLine(" La surface est : {0}",Qua1.Surface());
Console.ReadKey();
}
}
}
amazing
ممتاز
كيف اطلع ادخل النتيجه واطبعها بدون كتابتها داخل البرنامج حاولت وماضبطت معي
5:58🙊
١ لا
٢ الواجهات interfacs
٣ لا ادري
Inheritance describes an ( is-a ) relationship.
Implementing an interface describes a ( can-do ) relationship.
stackoverflow.com/questions/5816563/when-should-i-choose-inheritance-over-an-interface-when-designing-c-sharp-class
بشكل عام ، يذهب الحكم إلى شيء مثل هذا:
يصف الوراثة علاقة.
يصف تطبيق الواجهة علاقة يمكن تنفيذها.
لوضع هذا في مصطلحات أكثر واقعية إلى حد ما ، دعونا ننظر إلى مثال. فئة System.Drawing.Bitmap هي صورة (وعلى هذا النحو ، فإنها ترث من فئة الصورة) ، ولكنها أيضًا يمكن التخلص منها ، لذا فهي تنفذ واجهة IDisposable. كما أنه يمكن إجراء تسلسل ، بحيث يتم تنفيذه من واجهة ISerializable.
لكن من الناحية العملية ، غالبًا ما تستخدم الواجهات لمحاكاة الوراثة المتعددة في C #. إذا احتجت فئة المعالج إلى ورثها من شيء مثل System.ComponentModel.Component ، فليس لديك خيار سوى تطبيق واجهة IProcessor.
الحقيقة هي أن كلاً من الواجهات والطبقة الأساسية المجردة توفر عقدًا يحدد ما يمكن لفئة معينة القيام به. إنها خرافة شائعة مفادها أن الواجهات ضرورية لإعلان هذا العقد ، لكن هذا غير صحيح. أكبر ميزة في ذهني هي أن الطبقات الأساسية المجردة تسمح لك بتوفير وظيفة افتراضية للفئات الفرعية. ولكن إذا لم تكن هناك وظيفة افتراضية منطقية ، فلا يوجد ما يمنعك من وضع علامة على الطريقة نفسها على أنها مجردة ، مما يتطلب أن تنفذ الفئات المشتقة هذه العملية بنفسها ، مثلما إذا كانت ستقوم بتنفيذ واجهة.
للحصول على إجابات لأسئلة مثل هذا ، غالبًا ما أنتقل إلى إرشادات تصميم .NET Framework ، والتي يجب أن نقولها عن الاختيار بين الفئات والواجهات:
بشكل عام ، الطبقات هي البنية المفضلة لفضح التجريدات.
العيب الرئيسي للواجهات هو أنها أقل مرونة بكثير من الفئات عندما يتعلق الأمر بالسماح بتطوير واجهات برمجة التطبيقات. بمجرد شحن واجهة ، يتم إصلاح مجموعة أعضائها إلى الأبد. أي إضافات إلى الواجهة ستقطع الأنواع الموجودة التي تنفذ الواجهة.
يقدم الفصل مرونة أكثر. يمكنك إضافة أعضاء إلى الفئات التي قمت بشحنها بالفعل. طالما أن الطريقة ليست مجردة (أي ، طالما توفر تطبيقًا افتراضيًا للطريقة) ، تستمر أي فئات مشتقة موجودة في العمل دون تغيير.
[. . . ]
إحدى الحجج الأكثر شيوعًا لصالح الواجهات هي أنها تسمح بفصل العقد عن التنفيذ. ومع ذلك ، تفترض الوسيطة بشكل غير صحيح أنه لا يمكنك فصل العقود عن التنفيذ باستخدام الفئات. تعد الطبقات المجردة الموجودة في مجموعة منفصلة عن تطبيقاتها الملموسة طريقة رائعة لتحقيق هذا الفصل.
توصياتهم العامة هي كما يلي:
هل تفضل تحديد الطبقات على واجهات.
لا تستخدم فئات مجردة بدلاً من واجهات لفصل العقد من التطبيقات. فئات الملخصات ، إذا تم تعريفها بشكل صحيح ، تسمح لنفس الدرجة من الفصل بين العقد والتنفيذ.
حدد واجهة إذا كنت بحاجة إلى تقديم تسلسل هرمي متعدد الأشكال لأنواع القيم.
النظر في تحديد واجهات لتحقيق تأثير مماثل لذلك من الميراث متعددة.
يعبر كريس أندرسون عن اتفاق خاص مع هذه العقيدة الأخيرة ، بحجة أن:
تعمل أنواع الخلاصات بشكل أفضل كثيرًا ، وتتيح إمكانية التمدد في المستقبل ، لكنها تحرق أيضًا نوعك الأساسي الوحيد. تكون الواجهات مناسبة عندما تحدد حقًا عقدًا بين كائنين ثابتين بمرور الوقت. تعد أنواع القواعد المجردة أفضل لتحديد قاعدة مشتركة لمجموعة من الأنواع.
ممتاز