ירושה ב-C#: base, virtual, override, sealed ופולימורפיזם

ירושה מאפשרת למחלקה אחת להיבנות על גבי אחרת. המחלקה הנגזרת מקבלת את האיברים של מחלקת הבסיס, מוסיפה איברים משלה, ויכולה להחליף את ההתנהגות שמחלקת הבסיס מרשה לה להחליף. בשילוב עם מתודות virtual, היא נותנת פולימורפיזם: קוד שנכתב מול מחלקת הבסיס מריץ את ההתנהגות הנגזרת הנכונה בלי לדעת איזו מחלקה נגזרת יש לו.

גזירה של מחלקה

כתבו את מחלקת הבסיס אחרי נקודתיים. למחלקה הנגזרת יש כל מה שיש למחלקת הבסיס, ובנוסף מה שהיא מצהירה עליו:

using System;

class Vehicle
{
    public string Plate { get; }
    public int Km { get; private set; }

    public Vehicle(string plate) { Plate = plate; }

    public void Drive(int km) { Km += km; }
}

class Taxi : Vehicle
{
    public int Fares { get; private set; }

    public Taxi(string plate) : base(plate) { }

    public void Pickup(int km)
    {
        Drive(km);      // inherited method
        Fares++;
    }
}

class Program
{
    static void Main()
    {
        var taxi = new Taxi("TX-19");
        taxi.Pickup(12);
        taxi.Pickup(5);
        taxi.Drive(3);   // callers can use inherited members too

        Console.WriteLine($"{taxi.Plate}: {taxi.Km} km, {taxi.Fares} fares");
        Console.WriteLine(taxi is Vehicle);
    }
}

פלט:

TX-19: 20 km, 2 fares
True

מה מחלקה נגזרת מקבלת ומה לא:

• עובר בירושה: שדות, מאפיינים, מתודות, אירועים וטיפוסים מקוננים. הכול נמצא פיזית באובייקט.
• נגיש: רק מה שהבסיס מרשה: איברים public, protected ו-internal. איבר private של Vehicle קיים בתוך כל Taxi, אבל הקוד של Taxi לא יכול לפנות אליו בשמו. זו הסיבה שלמאפיין Km יש private set: Taxi יכולה לקרוא אותו, ומשנה אותו רק דרך Drive.
• לא עובר בירושה: בנאים. Taxi חייבת להצהיר על בנאי משלה ולשרשר לאחד מהבנאים של Vehicle עם : base(plate). העמוד על בנאים מראה באיזה סדר שניהם רצים.

כל מחלקה נגזרת בסופו של דבר מ-object, ולכן לכל אובייקט יש ToString(), Equals() ו-GetHashCode().

virtual ו-override

מחלקת בסיס מסמנת מתודה כ-virtual כדי לומר "מחלקות נגזרות רשאיות לספק גרסה משלהן". מחלקה נגזרת מחליפה אותה עם override. בתוך הדריסה, base.Method() קוראת לגרסה של מחלקת הבסיס.

using System;
using System.Collections.Generic;

class Notification
{
    public string To { get; }
    public Notification(string to) { To = to; }

    public virtual string Channel => "generic";

    public virtual string Render(string message) => $"[{Channel}] to {To}: {message}";
}

class Email : Notification
{
    public Email(string to) : base(to) { }
    public override string Channel => "email";

    public override string Render(string message) =>
        base.Render(message) + "\n  (unsubscribe link appended)";
}

class Sms : Notification
{
    public Sms(string to) : base(to) { }
    public override string Channel => "sms";

    // SMS messages are cut to 20 characters here to keep the demo short.
    public override string Render(string message) =>
        base.Render(message.Length > 20 ? message.Substring(0, 20).TrimEnd() + "..." : message);
}

class Program
{
    static void Main()
    {
        var outbox = new List<Notification>
        {
            new Email("lea@example.com"),
            new Sms("+351 912 000 111"),
            new Notification("ops-team"),
        };

        foreach (Notification n in outbox)
            Console.WriteLine(n.Render("Your order 1042 has shipped today"));
    }
}

פלט:

[email] to lea@example.com: Your order 1042 has shipped today
  (unsubscribe link appended)
[sms] to +351 912 000 111: Your order 1042 has...
[generic] to ops-team: Your order 1042 has shipped today

משתנה הלולאה הוא מטיפוס Notification, ובכל זאת כל אובייקט מוצג בדרך שלו. זה פולימורפיזם: הקריאה n.Render(...) נפתרת בזמן ריצה לפי הטיפוס האמיתי של האובייקט. שימו לב גם ש-base.Render ב-Email משתמשת ב-Channel, שהוא עצמו וירטואלי, ולכן מתודת הבסיס מדפיסה email ולא generic. קריאה וירטואלית בתוך מחלקת הבסיס עדיין מגיעה לדריסה.

גם מאפיינים יכולים להיות וירטואליים, כמו ש-Channel מראה. שדות לא.

הקומפיילר מחייב את שתי מילות המפתח. כתיבה של override על מתודה שאינה virtual היא שגיאה CS0506 ("cannot override inherited member ... because it is not marked virtual, abstract, or override"). השמטה של override כשמתודת הבסיס וירטואלית היא רק אזהרה, והיא משנה את המשמעות לגמרי, כמו שהסעיף הבא מראה.

new מול override: הסתרה במקום דריסה

אם מחלקה נגזרת מצהירה על מתודה עם אותה חתימה כמו מתודת בסיס בלי לכתוב override, היא מסתירה את מתודת הבסיס. הקומפיילר מזהיר (CS0114 למתודת בסיס וירטואלית, CS0108 בכל מקרה אחר) ומציע את מילת המפתח new, שמשתיקה את האזהרה אבל שומרת על התנהגות ההסתרה:

using System;

class Report
{
    public virtual string Title() => "Report";
}

class SalesReport : Report
{
    public override string Title() => "Sales report";
}

class DraftReport : Report
{
    public new string Title() => "Draft report";
}

class Program
{
    static void Main()
    {
        Report a = new SalesReport();
        Report b = new DraftReport();
        DraftReport c = new DraftReport();

        Console.WriteLine(a.Title());
        Console.WriteLine(b.Title());
        Console.WriteLine(c.Title());
    }
}

פלט:

Sales report
Report
Draft report

b ו-c הם אותו סוג אובייקט, ובכל זאת הם מדפיסים כותרות שונות. עם new, המתודה שנבחרת תלויה בטיפוס של המשתנה, ונקבעת בזמן קומפילציה. קוד שמטפל בדוחות כ-Report (רשימה, פרמטר של מתודה, callback של framework) אף פעם לא רואה את DraftReport.Title. זה כמעט אף פעם לא מה שרוצים. השתמשו ב-override לפולימורפיזם; new קיים בעיקר למקרה שבו מחלקת בסיס שאינה בשליטתכם מוסיפה איבר שהשם שלו מתנגש עם איבר שכבר יש לכם.

sealed

sealed על מחלקה אוסר לגזור ממנה:

sealed class Invoice { }
class CorrectedInvoice : Invoice { }
// error CS0509: 'CorrectedInvoice': cannot derive from sealed type 'Invoice'

string היא sealed, וכך גם טיפוסים רבים של ה-framework. על דריסה, sealed עוצר את השרשרת ברמה הזו:

class Shape { public virtual string Name() => "shape"; }
class Square : Shape { public sealed override string Name() => "square"; }
class Tile : Square { public override string Name() => "tile"; }
// error CS0239: 'Tile.Name()': cannot override inherited member 'Square.Name()' because it is sealed

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

מחלקת בסיס אחת, הרבה ממשקים

למחלקה ב-C# יש בדיוק מחלקת בסיס אחת. class Admin : User, Employee היא שגיאה CS1721 ("cannot have multiple base classes"). עם זאת, מחלקה יכולה לממש כל מספר של ממשקים לצד מחלקת הבסיס שלה:

class Admin : User, IAuditable, IComparable<Admin>
{
    // base class first, then interfaces, in any order
}

השתמשו במחלקת בסיס עבור "הוא סוג של, וחולק איתו מימוש", ובממשקים עבור "יודע לעשות". כשמחלקת הבסיס קיימת רק כדי לחייב מחלקות נגזרות להשלים כמה מתודות, מחלקה אבסטרקטית היא הכלי.

המרה למעלה ולמטה בהיררכיה

תמיד אפשר להשתמש באובייקט נגזר במקום שבו מצופה טיפוס הבסיס שלו. ה-upcast הזה מרומז ולא יכול להיכשל. בכיוון השני, downcast צריך המרה מפורשת ונכשל בזמן ריצה אם האובייקט אינו מהטיפוס הזה:

using System;

class Animal { public string Name; }
class Dog : Animal { public void Fetch() => Console.WriteLine($"{Name} fetches the ball"); }
class Cat : Animal { }

class Program
{
    static void Main()
    {
        Animal pet = new Dog { Name = "Rex" };   // upcast: implicit
        Animal other = new Cat { Name = "Tom" };

        Dog d = (Dog)pet;                        // downcast: explicit, succeeds
        d.Fetch();

        try
        {
            Dog wrong = (Dog)other;              // the object is a Cat
        }
        catch (InvalidCastException)
        {
            Console.WriteLine("InvalidCastException: Tom is not a Dog");
        }

        Dog maybe = other as Dog;                // as: null instead of an exception
        Console.WriteLine(maybe == null);

        if (pet is Dog dog)                      // is: test and cast in one step
            dog.Fetch();
    }
}

פלט:

Rex fetches the ball
InvalidCastException: Tom is not a Dog
True
Rex fetches the ball

כתיבה של Dog d = pet; בלי ההמרה היא שגיאת קומפילציה (CS0266: "An explicit conversion exists (are you missing a cast?)"), כי הקומפיילר יודע רק ש-pet הוא Animal כלשהו. העדיפו is עם משתנה כשהאובייקט עשוי להיות מטיפוס אחר, והמרה פשוטה רק כשכל דבר אחר יהיה באג. downcasting תכוף הוא סימן לבעיה בתכנון: בדרך כלל זה אומר שההתנהגות שייכת למתודה וירטואלית במחלקת הבסיס. העמוד על pattern matching מכסה את כל הצורות של is.

ירושה ואוספים

פולימורפיזם עובד איבר אחרי איבר, אבל אוספים גנריים של טיפוס נגזר הם לא אוספים של טיפוס הבסיס: List<Animal> animals = new List<Dog>(); לא מתקמפל, כי אז הרשימה הייתה מקבלת Cat. תצוגות לקריאה בלבד הן covariant, ולכן IEnumerable<Animal> animals = new List<Dog>(); בסדר. העמוד על generics מסביר למה.

טעויות נפוצות

• לשכוח override. המתודה מתקמפלת עם אזהרה ומסתירה בשקט במקום לדרוס. התייחסו ל-CS0114 כשגיאה.
• להפוך הכול ל-virtual. כל איבר וירטואלי הוא הבטחה למחלקות נגזרות לגבי מתי קוראים לו ומה הוא רשאי להניח. סמנו רק את נקודות ההרחבה שאתם מתכוונים אליהן.
• היררכיות עמוקות. שלוש או ארבע רמות של ירושה מקשות לדעת איזו גרסה של מתודה רצה. הרכבה (composition), מחלקה שמחזיקה אובייקט אחר וקוראת לו, היא לעיתים קרובות פשוטה יותר מרמה חדשה.
• קריאה למתודות וירטואליות מתוך בנאי. הדריסה רצה לפני הגוף של הבנאי הנגזר, ולכן כל שדה שהגוף הזה מאתחל עדיין מחזיק את ערך ברירת המחדל שלו.
• שימוש בירושה רק כדי לעשות שימוש חוזר בקוד. אם Stack יורשת מ-List, מי שקורא יכול לבצע Insert לאמצע המחסנית שלכם. החזיקו במקום זאת List בשדה פרטי.