Klasa abstrakcyjna TypeScript - Kiedy warto jej użyć?

Klasa abstrakcyjna w TypeScript przydaje się wtedy, gdy kilka obiektów ma wspólny rdzeń, ale różni się szczegółami zachowania. W praktyce typescript abstract class pozwala połączyć wspólny kod z kontraktem, który wymusza implementację najważniejszych elementów w klasach potomnych. To dobry temat zarówno dla osób uczących się dziedziczenia, jak i dla tych, którzy chcą porządkować większy projekt bez przypadkowego duplikowania logiki.

W tym artykule pokazuję, czym taka klasa jest, jak działa w kodzie, kiedy ma sens zamiast interfejsu i jakie ma ograniczenia po stronie JavaScriptu, bo właśnie tam najczęściej pojawiają się nieporozumienia.

Czym jest klasa abstrakcyjna w TypeScript

Klasa abstrakcyjna to klasa bazowa, której nie instancjonujesz bezpośrednio. Służy jako wzorzec dla innych klas: opisuje, co potomkowie mają umieć, ale sama nie musi być kompletna. To ważne rozróżnienie, bo taka baza może zawierać normalne metody, własne pola, konstruktor i jednocześnie elementy oznaczone jako abstrakcyjne.

Najczęściej spotkasz abstrakcyjne metody, ale TypeScript pozwala też definiować abstrakcyjne pola oraz gettery i settery. W praktyce oznacza to tyle, że klasa bazowa może powiedzieć: „każdy potomek ma dostarczyć tę część”, a resztę wspólnej logiki mogę dać od razu.

abstract class Animal {
  constructor(protected readonly name: string) {}

  abstract makeSound(): string;

  move(): string {
    return `${this.name} porusza się do przodu`;
  }
}

class Dog extends Animal {
  makeSound(): string {
    return "hau";
  }
}

W tym przykładzie `Animal` nie jest pełną klasą, więc nie utworzysz jej przez `new Animal("Pimpek")`. Za to `Dog` musi zaimplementować `makeSound()`, bo bez tego nie spełni kontraktu narzuconego przez bazę. Jeśli klasa potomna ma własny konstruktor, musi też wywołać `super(...)` zanim użyje `this`.

To prowadzi do pytania, jak taki kontrakt wygląda w konkretnym kodzie dziedziczenia.

Jak działa dziedziczenie w praktyce

W praktyce abstrakcja najlepiej widać tam, gdzie jedna klasa trzyma wspólny przepływ, a potomkowie wypełniają tylko zmienne fragmenty. Ja zwykle myślę o tym jak o szkielecie algorytmu: baza decyduje o kolejności kroków, a klasy dziedziczące odpowiadają za szczegóły wykonania.

abstract class ReportExporter {
  export(rows: string[]): string {
    this.validate(rows);
    const content = this.buildContent(rows);
    this.log(content);
    return content;
  }

  protected validate(rows: string[]): void {
    if (rows.length === 0) {
      throw new Error("Brak danych do eksportu");
    }
  }

  protected log(content: string): void {
    console.log(`Wygenerowano raport: ${content.length} znaków`);
  }

  protected abstract buildContent(rows: string[]): string;
}

class CsvExporter extends ReportExporter {
  protected buildContent(rows: string[]): string {
    return rows.join(",\n");
  }
}

class JsonExporter extends ReportExporter {
  protected buildContent(rows: string[]): string {
    return JSON.stringify(rows);
  }
}

Tutaj metoda `export()` ustala wspólny proces: walidacja, budowa treści, logowanie. To klasy potomne decydują tylko o tym, jak zbudować wynik. Taki układ jest czytelny, bo logika wspólna nie rozjeżdża się po wielu plikach, a zmienny fragment pozostaje dobrze nazwany i łatwy do podmiany.

Właśnie tu naturalnie pojawia się porównanie z interfejsem.

Kiedy wybrać klasę abstrakcyjną zamiast interfejsu

Najczęstszy dylemat brzmi: czy wystarczy interfejs, czy potrzebna jest klasa abstrakcyjna? Ja patrzę na to prosto. Jeśli potrzebujesz tylko opisu tego, co obiekt ma robić, interfejs jest lżejszy. Jeśli chcesz dać też wspólny kod, wspólny stan albo gotowy szkielet działania, klasa abstrakcyjna ma przewagę.

W skrócie: interfejs opisuje rolę, a klasa abstrakcyjna opisuje rolę i część wykonania. To ważna różnica w projektowaniu, bo zbyt szybkie sięganie po dziedziczenie potrafi usztywnić architekturę. Jeśli chcesz tylko wymusić kilka metod w różnych klasach, interfejs bywa po prostu bardziej elastyczny.

Sama decyzja o wyborze narzędzia nie wystarczy, bo w JavaScript trzeba pamiętać o granicach działania TypeScriptu.

Czego nie robi w JavaScript i gdzie są granice

Tu pojawia się częsty błąd myślowy: wiele osób traktuje klasę abstrakcyjną jak twardą blokadę na poziomie runtime. To nie tak. TypeScript sprawdza abstrakcję podczas kompilacji, ale po przejściu do JavaScriptu zostaje zwykła klasa ES. Innymi słowy, mechanizm jest bardzo użyteczny, ale nadal opiera się na typach, a nie na osobnej, wbudowanej w silnik regule.

To oznacza kilka praktycznych konsekwencji:

• Nie licz na to, że abstrakcja ochroni Cię w środowisku, w którym kod TypeScript został już zamieniony na JavaScript.
• Nie wywołasz metod abstrakcyjnych przez `super`, bo nie mają własnej implementacji.
• Nie próbuj ukrywać elementów kontraktu za `private`, bo klasa potomna musi je widzieć, aby je uzupełnić.
• Jeśli nie implementujesz wszystkich wymaganych elementów, kompilator zgłosi błąd i to jest właśnie ta część ochrony, na której warto polegać.

W praktyce lubię myśleć o klasie abstrakcyjnej jak o bardzo dobrym strażniku projektu, ale nie o magicznym murze. Jeśli ktoś obejdzie typowanie albo pracuje bez TypeScriptu, reguła przestaje działać. Dlatego abstrakcja ma sens przede wszystkim tam, gdzie trzymasz dyscyplinę na poziomie kodu źródłowego i procesu budowania aplikacji.

Jeśli te ograniczenia są jasne, można przejść do wzorca, który realnie pomaga w aplikacjach webowych.

Praktyczny wzorzec dla aplikacji webowej

W projektach webowych klasa abstrakcyjna dobrze sprawdza się tam, gdzie masz kilka wariantów tego samego procesu: eksport danych, obsługę kanałów powiadomień, integracje z API albo przetwarzanie plików. Ja najczęściej wybieram ją wtedy, gdy chcę zamknąć wspólny przepływ w jednym miejscu i dopuścić tylko kontrolowane różnice.

Dobry przykład to eksport raportów. W aplikacji możesz mieć CSV, JSON i PDF, ale wszystkie wersje zwykle potrzebują tych samych kroków: walidacji danych, budowy zawartości i logowania operacji. Klasa bazowa porządkuje ten przepływ, a każda implementacja daje tylko swój format wyjścia.

abstract class ReportExporter {
  export(rows: string[]): string {
    this.validate(rows);
    const content = this.buildContent(rows);
    this.afterExport(content);
    return content;
  }

  protected validate(rows: string[]): void {
    if (rows.length === 0) {
      throw new Error("Brak danych do eksportu");
    }
  }

  protected afterExport(content: string): void {
    console.log(`Gotowy raport o długości ${content.length}`);
  }

  protected abstract buildContent(rows: string[]): string;
}

class CsvExporter extends ReportExporter {
  protected buildContent(rows: string[]): string {
    return rows.join("\n");
  }
}

class JsonExporter extends ReportExporter {
  protected buildContent(rows: string[]): string {
    return JSON.stringify(rows, null, 2);
  }
}

Co tu jest istotne? Po pierwsze, wspólna logika nie duplikuje się w każdej klasie. Po drugie, jeśli dodasz nowy format, dopisujesz tylko jedną klasę potomną zamiast kopiować cały proces. Po trzecie, testy są prostsze, bo możesz osobno sprawdzić zachowanie bazowe i osobno konkretne formaty.

Taki wzorzec działa dobrze, gdy różnice między implementacjami są wąskie i przewidywalne. Jeśli wariantów robi się zbyt dużo albo zaczynasz dopisywać coraz więcej wyjątków, dziedziczenie przestaje być wygodne i lepiej rozważyć kompozycję albo zwykłe funkcje pomocnicze.

Na końcu zostaje już tylko pytanie, jak nie zrobić z abstrakcji ciężaru.

Jak projektować hierarchię, żeby nie przesadzić

Najlepsza klasa abstrakcyjna to taka, której prawie nie widać w użyciu, a mimo to porządkuje kod. Ja trzymam się kilku prostych zasad: baza ma być mała, stabilna i naprawdę wspólna dla wszystkich potomków. Jeśli zaczynasz dorzucać do niej metody, które dotyczą tylko jednej klasy, to zwykle znak, że projekt skręca w złą stronę.

• Nie twórz abstrakcji tylko dlatego, że „tak się robi”.
• Jeśli masz jedną klasę potomną i brak realnej wspólnej logiki, bazę można odłożyć na później.
• Gdy hierarchia rośnie zbyt głęboko, czytelność spada szybciej niż zyski z reużycia.
• Preferuj mały, jasny kontrakt zamiast dużej klasy bazowej, która wie wszystko o wszystkim.
• Jeśli kilka klas ma wspólne zachowanie, ale nie wspólną naturę, kompozycja bywa lepsza niż dziedziczenie.

W praktyce dobra abstrakcja ma usuwać powtórzenia i wymuszać spójność, a nie imponować rozmiarem hierarchii. Gdy trzymasz się tej zasady, klasę abstrakcyjną czyta się łatwo, a zespół szybciej rozumie, co jest obowiązkowe, a co opcjonalne. To właśnie dlatego świadome użycie takiej bazy daje więcej porządku niż kolejne warstwy przypadkowych klas.