ירושה ב-TypeScript: extends, super ו-override

מחלקה ב-TypeScript יורשת ממחלקה אחרת עם extends. תת-המחלקה מקבלת כל שדה וכל מתודה של ההורה, קוראת לבנאי של ההורה עם super(...), ויכולה לדרוס מתודות, ו-TypeScript בודק שכל דריסה נשארת תואמת לטיפוסים של ההורה.

class Animal {
    constructor(public name: string) {}

    speak(): string {
        return `${this.name} makes a sound`;
    }
}

class Dog extends Animal {
    constructor(name: string, public breed: string) {
        super(name); // call the parent constructor first
    }

    override speak(): string {
        return `${super.speak()}: woof`; // call the parent method
    }
}

const rex = new Dog("Rex", "beagle");
console.log(rex.speak());          // Rex makes a sound: woof
console.log(rex);                  // Dog { name: 'Rex', breed: 'beagle' }
console.log(rex instanceof Animal); // true

זו ירושת מחלקות של JavaScript (ראו ירושה ב-JavaScript על שרשרת ה-prototype שמאחוריה). TypeScript מוסיף את בדיקות הטיפוסים: אפשר להשים Dog בכל מקום שבו מצופה Animal, והקומפיילר מוודא את הדריסה ואת הקריאה ל-super.

דריסת מתודות

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

class Formatter {
    format(value: number): string {
        return value.toString();
    }
}

class CurrencyFormatter extends Formatter {
    // Compatible: accepts more (number | bigint) and returns the same type.
    override format(value: number | bigint): string {
        return `$${value.toLocaleString("en-US")}`;
    }
}

const formatters: Formatter[] = [new Formatter(), new CurrencyFormatter()];
for (const f of formatters) console.log(f.format(1234567));
// 1234567
// $1,234,567

שינוי הפרמטר ל-value: string היה השגיאה TS2416: Property 'format' in type 'CurrencyFormatter' is not assignable to the same property in base type 'Formatter'. הלולאה מראה למה: היא קוראת ל-format עם מספר על כל איבר, בלי לדעת איזו תת-מחלקה יש לה ביד.

יש חור אחד. פרמטרים של מתודות מושווים bivariantly, ולכן דריסה שמקבלת טיפוס צר יותר, כמו format(value: 1 | 2), מתקמפלת למרות שהלולאה עדיין יכולה להעביר לה 1234567. טיפוסי החזרה נבדקים בקפדנות: החזרה של number במקום string היא TS2416.

מילת המפתח override ו-noImplicitOverride

override אומרת "האיבר הזה מחליף איבר במחלקת הבסיס", והקומפיילר מחזיק אתכם לזה. אם אין בבסיס איבר כזה (שגיאת כתיב, או מתודה שמישהו שינה את שמה בהורה), זו שגיאה:

// This does not compile: the parent has no method called 'speek'.
class Animal {
    speak(): string {
        return "...";
    }
}

class Cat extends Animal {
    override speek(): string {
        return "meow";
    }
}

console.log(new Cat().speak());

index.ts(9,14): error TS4117: This member cannot have an 'override' modifier because it is not declared in the base class 'Animal'. Did you mean 'speak'?

בלי override, שגיאת הכתיב הזו מתקמפלת ו-speak() מחזירה בשקט "...". מילת המפתח עוזרת רק איפה שהיא כתובה, אז הפעילו את noImplicitOverride ב-tsconfig.json. אז כל מתודה שדורסת איבר של הבסיס חייבת לציין זאת, ו-speak() רגילה בתת-מחלקה היא השגיאה TS4114 (This member must have an 'override' modifier because it overrides a member in the base class 'Animal').

{
    "compilerOptions": {
        "strict": true,
        "noImplicitOverride": true
    }
}

noImplicitOverride אינה חלק מ-strict; צריך להוסיף אותה בעצמכם. override נמחקת מה-JavaScript המקומפל.

איברים protected בתתי-מחלקות

איברים private של ההורה לא נראים בתת-המחלקה. איברים protected כן נראים, וזו הסיבה ש-protected קיים: זה ה-API שמחלקת הורה מציעה לילדים שלה.

class Counter {
    protected count = 0;
    private log: string[] = [];

    increment(): void {
        this.count++;
        this.log.push(`now ${this.count}`);
    }
}

class StepCounter extends Counter {
    constructor(private step: number) {
        super();
    }

    override increment(): void {
        this.count += this.step - 1; // protected: allowed
        super.increment();
        // this.log is private to Counter: a compile error here
    }

    get value(): number {
        return this.count;
    }
}

const c = new StepCounter(5);
c.increment();
c.increment();
console.log(c.value); // 10

ראו access modifiers לכללים המלאים, כולל למה לא private ולא protected נאכפים בזמן ריצה.

הצהרה מחדש על שדה עם טיפוס צר יותר

לעתים קרובות תת-מחלקה יודעת ששדה מחזיק משהו ספציפי יותר ממה שההורה אומר. להצהרה מחדש שלו כ-pet: Dog יש השפעה בזמן ריצה עם class fields מודרניים: השדה של תת-המחלקה מאותחל ל-undefined אחרי ש-super() חוזר, ומוחק את מה שהבנאי של ההורה שמר. אלא אם הבנאי של תת-המחלקה משים אותו שוב, TypeScript מדווח על כך כ-TS2612 (Property 'pet' will overwrite the base property in 'Home'). השתמשו ב-declare כדי לשנות רק את הטיפוס:

class Animal {
    name = "pet";
}
class Dog extends Animal {
    bark(): string {
        return "woof";
    }
}

class Home {
    pet: Animal;
    constructor(pet: Animal) {
        this.pet = pet;
    }
}

class Kennel extends Home {
    declare pet: Dog; // type only: no field is emitted

    constructor(dog: Dog) {
        super(dog);
    }
}

console.log(new Kennel(new Dog()).pet.bark()); // woof

declare לא מייצר כלום, ולכן הערך שהבנאי של Home קבע נשמר. הבנאי שמקבל רק Dog הוא מה שהופך את הטיפוס הצר יותר לנכון.

implements מול extends

שתי מילות המפתח עונות על שאלות שונות, ומחלקה יכולה להשתמש בשתיהן.

interface Serializable {
    serialize(): string;
}

class Entity {
    constructor(readonly id: number) {}
}

class User extends Entity implements Serializable {
    constructor(id: number, readonly email: string) {
        super(id);
    }

    serialize(): string {
        return JSON.stringify({ id: this.id, email: this.email });
    }
}

const u = new User(1, "ada@example.com");
console.log(u.serialize()); // {"id":1,"email":"ada@example.com"}

מחלקה יכולה להרחיב רק מחלקה אחת (TS1174: Classes can only extend a single class). כדי לשלב התנהגות מכמה מקומות, ממשו כמה interfaces ושתפו קוד דרך קומפוזיציה (שדה שמחזיק אובייקט עזר) או mixins.

Mixins

mixin היא פונקציה שמקבלת מחלקה ומחזירה תת-מחלקה שלה. היא נותנת סוג של ירושה מרובה שעוברת בדיקת טיפוסים:

type Constructor<T = {}> = new (...args: any[]) => T;

function Timestamped<TBase extends Constructor>(Base: TBase) {
    return class extends Base {
        createdAt = new Date("2024-03-15T10:30:00Z");
    };
}

function Tagged<TBase extends Constructor>(Base: TBase) {
    return class extends Base {
        tags: string[] = [];
        tag(t: string): this {
            this.tags.push(t);
            return this;
        }
    };
}

class Note {
    constructor(public text: string) {}
}

const TaggedNote = Tagged(Timestamped(Note));
const n = new TaggedNote("buy milk").tag("home");
console.log(n.text, n.tags, n.createdAt.toISOString());
// buy milk [ 'home' ] 2024-03-15T10:30:00.000Z

ה-any[] ב-Constructor הכרחי: TypeScript מקבל בסיס של mixin רק אם הבנאי שלו מקבל פרמטר rest יחיד מהטיפוס any[]. mixins עובדים, אבל הם מקשים על קריאת הטיפוסים ו-stack traces, אז העדיפו קודם קומפוזיציה.

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

• קריאה למתודה שאפשר לדרוס מתוך הבנאי של הבסיס. הבנאי של הבסיס רץ לפני שהשדות של תת-המחלקה מאותחלים, ולכן דריסה שקוראת את this.items רואה undefined, וקריאה כמו this.items.push(x) זורקת TypeError בזמן ריצה. TypeScript לא תופס את זה.
• שכחה של super(...) או קריאה מאוחרת לו. השגיאות TS2377 ו-TS17009; ההורה חייב לבנות את האובייקט לפני שתת-המחלקה נוגעת ב-this.
• הצהרה מחדש על שדה של ההורה בלי declare. השדה של תת-המחלקה מאפס אותו ל-undefined.
• היררכיות עמוקות. כל רמה קושרת את הילד לפרטים הפנימיים של ההורה. שתי רמות בדרך כלל מספיקות; מעבר לזה העדיפו קומפוזיציה או interfaces.