ירושה מרובה ב java

[justme5]

ירושה מרובה ב java

מדוע אין ירושה מרובה ב java (ירושה של class-ים, לא מדובר על interfaces)? איזה בעיות זה פותר? האם הבעיות האלו לא קיימות ב ++c, ששם כן מרשים ירושה מרובה? אפשר דוגמא?

 

[voguemaster]

ירושה מרובה

לרוב זו צרה צרורה או מצביע על DESIGN רשלני. מעטים מאוד המקרים שבהם באמת באמת צריך ירושה מרובה. ג'אווה פותרת את הבעיה ע"י אלימינציה של ירושה מרובה. הפיתרון החלופי הוא interfaces שזה מזכיר ירושה מרובה אבל לא ממש אותו הדבר.

 

[justme5]

אפשר דוגמא?

בבקשה?

 

[voguemaster]

דוגמא ל... ?

 

[justme5]

דוגמא ל design רשלני

מהסוג שתיארת.

 

[voguemaster]

בעיית היהלום

יש לך מחלקה A, היא מגדירה פונק' וירטואלית טהורה שנקראת print. יש לך מחלקה B שיורשת מ-A, היא מממשת את print בצורה מסוימת (גם היא וירטואלית) יש לך מחלקה C שיורשת מ-A, גם היא מממשת את print בצורה מסוימת (צורה אחרת מ-B). עכשיו אני רוצה לרשת התנהגות גם מ-B וגם מ-C למחלקה חדשה שנקרא לה D. יש לקומפיילר (ולי) בעיה בקריאה לפונק' print. צריך להגיד לו ספציפית בכל קריאה ל-print לאיזו גרסא אני רוצה לקרוא (של B או של C). כל הרעיון הזה נוגד את רעיון ה-object oriented. ותתפלא, הדברים האלה קורים יופי, אולי לא בפשטות כמו שתיארתי אבל קורים.

 

[zeevb]

שני מאמרים קצרים בנושא

לינקים מצורפים

 

[DadleFish]

פתרון אפשרי נוסף הוא הכלה, אגב.

 

[מאה קולפה]

שום רשלני

ירושה מרובה היא לפעמים הפתרון האלגנטי ביותר לבעיות מסויימות. המימוש של iostream הוא לדעתך design רשלני? אפשר להביא עוד דוגמאות שבהן ירושה מרובה עונה יפה מאד על צרכי תיכנון. בעיית יהלום קיימת וצריך להיות מודעים לה אם כותבים ב++C יש שפות OO יותר נקיות שבהן הבעיה לא קיימת (למשל EIFFEL). ואגב התיכנון של iostream הוא עם יהלום ואין בו שום בעיה. נכון שאפשר לדמות ירושה מרובה בשיטות אחרות, נכון שאפשר לתכנן ללא ירושה מרובה (אפשר גם ללא ירושה בכלל) אבל אי אפשר לפסול שיטה באופן גורף. זה חלק מ OOP/D וצריך להכיר את זה. מציע לקרוא את הפרק על ירושה בספר של ברטרנד מאייר Object Oriented Software Construction שהוא אמנם מלמד EIFFEL אבל השפה היא לא העיקר. רצוי לקרוא את כולו - ספר מאלף.

 

[voguemaster]

הדעות חלוקות בנושא

ברטרנד אולי מצדד בירושה מרובה אבל מאיירס לא. סתם דוגמא.