בהמשך לפוסט הקודם שלי בנושא, להלן התשובה לשאלה, וכמה הבהרות.

ראשית - שימו לב שהשאלה אינה "מה ההבדל בין Abstract Class ו- Interface". קיבלתי לא מעט תשובות (נכונות!) שענו על זה, אבל זה לא מה ששאלתי. השאלה היא: "מה ההבדל בין Abstract Class שמכיל רק פונקציות Abstract, ובין Interface". ברור שב- Abstract Class ניתן להוסיף פונקציונליות, אבל זה לא המקרה...

בנוסף - חשוב לי להדגיש משהו עקרוני. אנחנו לעולם לא פוסלים (או מקבלים, לצורך העניין...) מועמד על סמך שאלה אחת, חשובה ככל שתהיה. יש עוד לא מעט פרמטרים שעומדים למבחן. ידע ועומק טכנולוגי הם פרמטר חשוב, אבל לא היחיד. ולכן, גם אם לא ידעתם את התשובה לשאלה הזו, אין המשמעות של זה שאינכם מתאימים לעבודה אצלנו...

ולתשובה:

הראשון ששלח את התשובה הנכונה ביקש שלא אחשוף את פרטיו, ולכן רק אעתיק את החלק הרלוונטי מהתשובה שלו:

"מחלקה יכולה לממש כמה ממשקים, אך רק מחלקת-אב אחת בלבד"

או, בז'רגון המקצועי - ירושה מרובה. ב- .NET, כידוע,  לא קיימת ירושה מרובה של Classes, אך ניתן לממש מספר Interfaces.

שתי הערות בקשר לנושא הזה:

1. חשוב לשים לב לטרמינולוגיה - Class אינו יורש Interface, אלא מממש אותו. לעומת זאת, Class כן יורש Class אחר. למי מכם שכותב ב- VB.NET ההבדל בולט לעין, משום שאלו המינוחים בהם עושים שימוש: Inherits לעומת Implements. ב- C#, לעומת זאת, אין הבדל בין ציון ירושה מ- Class ומימוש Interface. מספר מיילים שקיבלתי השתמשו במינוח המוטעה, וציינו ירושה של Interface. עם זאת, חשוב לשים לב שקיימת ירושה בין Interfaces, כלומר - Interface יכול לרשת ולהרחיב הגדרות של Interface אחר. למעשה  - Interface אחד יכול לרשת מספר Interfaces - והרי לנו ירושה מרובה ב- .NET...

2. אחד המיילים שקיבלתי ציין את המחסור בירושה מרובה כחיסרון. לטעמי, העובדה שאין ירושה מרובה היא דווקא יתרון. כאחד שכתב ב- C++, Java ו- .NET, מעולם לא נתקלתי במצב בו ירושה מרובה היא הפיתרון היחיד, אך כן נתקלתי בבעיות שזה יוצר. הבעיה העיקרית היא כמובן פרדוקס היהלום, אבל זה עלול ליצור בעיות נוספות. אשמח לשמוע את דעתכם בעניין.