Odpowiedź.

Historia pytania

W przeciwieństwie do wielu języków obiektowych, TypeScript realizuje typizację strukturalną (duck typing): obiekt uznawany jest za zgodny z typem, jeśli ma wszystkie wymagane właściwości, niezależnie od tego, czy wyraźnie zadeklarowano go jako tego typu.

Problem

Ta elastyczność czasami prowadzi do nieoczekiwanego uznawania obiektów za typ, jeśli struktura się zgadza, chociaż w rzeczywistości nie są one związane semantycznie. Jest to niebezpieczne w przypadku skomplikowanych modeli danych, gdy struktura zgadza się przypadkowo.

Rozwiązanie

Zawsze poprawnie strukturyzuj typy obiektów, minimalizuj zbieżności strukturalne różnych bytów, w krytycznych przypadkach używaj dodatkowych właściwości lub symboli do „nominacji” typów.

Przykład kodu:

interface Point { x: number; y: number; }
interface Pixel { x: number; y: number; }

function drawPoint(p: Point) {
  console.log(p.x, p.y);
}

const pixel: Pixel = { x: 1, y: 2 };
drawPoint(pixel); // OK, typy są zgodne strukturalnie

Kluczowe cechy:

Sprawdzanie według struktury (właściwości i ich typy), a nie według nazwy typu
Łatwość integracji z istniejącym kodem JS
Potencjalne konflikty przy zbieżności struktur różnych obiektów pod względem semantycznym

Pytania z zastrzeżeniem.

Czy zbieżność struktury dwóch interfejsów oznacza, że są one całkowicie zamienne?

Możliwe według struktury, ale nie według logiki programu. Jest to dozwolone na poziomie kompilatora, ale może prowadzić do błędów logicznych (na przykład Point i Pixel wyżej).

Czy można zakazać strukturalnej zgodności dla niektórego typu?

Całkowicie nie, ale można dodać unikalną właściwość (na przykład z symbolem):

interface Brand {
  _brand: unique symbol;
}

Teraz inny obiekt nie będzie mógł naśladować tego typu bez takiego samego unikalnego symbolu.

Czym różni się typizacja strukturalna od nominatywnej?

Strukturalna — według obecności struktury, nominatywna — według zbieżności nazwy typu w określonym namespace. W TS domyślnie zawsze występuje typizacja strukturalna.

Typowe błędy i antywzorce

Błędne uznawanie niespowiązanych obiektów o takiej samej strukturze
Całkowite zbieżności sygnatur — niemożność oddzielenia konceptualnie różnych typów
Fałszywe poczucie bezpieczeństwa typów

Przykład z życia

Negatywny przypadek

W szeregu bytów niezamierzenie zbieżne były pola (na przykład, User i Admin jako {id: number, name: string}), co doprowadziło do zamieszania przy pracy z kontraktami API.

Plusy:

Mniej kodu, łatwiej rozszerzać nowe byty

Minusy:

Trudno śledzić błędy logiczne, których nie wykrywa kompilator

Pozytywny przypadek

Wykorzystanie unikalnych „znaczników” symboli i niestandardowych pól do rozgraniczenia semantycznie różnych typów o identycznej strukturze.