Antwoord.

Geschiedenis van de vraag

In tegenstelling tot veel objectgeoriënteerde talen implementeert TypeScript structurele typisatie (duck typing): een object wordt als compatibel met een type beschouwd als het alle vereiste eigenschappen heeft, ongeacht of het expliciet van dat type is gedeclareerd.

Probleem

Deze flexibiliteit leidt soms tot onverwachte acceptatie van objecten als type, als de structuur overeenkomt, terwijl ze in feite niet inhoudelijk gerelateerd zijn. Dit is gevaarlijk bij complexe datamodellen, wanneer de structuur toevallig overeenkomt.

Oplossing

Structuur de types van objecten altijd goed, minimaliseer structurele overeenkomsten tussen verschillende entiteiten, en gebruik voor kritieke gevallen extra eigenschappen of symbolen voor de "nominalisatie" van types.

Codevoorbeeld:

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

function tekenPunt(p: Punt) {
  console.log(p.x, p.y);
}

const pixel: Pixel = { x: 1, y: 2 };
tekenPunt(pixel); // OK, types zijn structureel compatibel

Belangrijke kenmerken:

Controle op basis van structuur (eigenschappen en hun types), niet op basis van type naam
Eenvoudige integratie met bestaande JS-code
Mogelijke conflicten bij overeenkomende structuren van inhoudelijk verschillende objecten

Vragen met een valkuil.

Als de structuur van twee interfaces overeenkomt, betekent dit dan dat ze volledig uitwisselbaar zijn?

Misschien qua structuur, maar niet qua programmaloogica. Dit is toegestaan op het niveau van de compiler, maar kan leiden tot logische fouten (bijvoorbeeld, Punt en Pixel hierboven).

Is het mogelijk om structurele compatibiliteit voor een bepaald type te verbieden?

Volledig niet, maar het is mogelijk een unieke eigenschap toe te voegen (bijvoorbeeld met een symbool):

interface Merk {
  _merk: unieke symbool;
}

Nu kan een ander object dit type niet imiteren zonder hetzelfde unieke symbool.

Wat is het verschil tussen structurele en nominale typisatie?

Structureel is gebaseerd op de aanwezigheid van structuur, nominaal op de overeenstemming van de type naam in een bepaalde namespace. In TS is de standaard altijd structurele typisatie.

Typefouten en anti-patronen

Ongeldige acceptatie van niet-gerelateerde objecten met een gelijke structuur
Volledige overeenstemming van handtekeningen - onvermogen om conceptueel verschillende types te scheiden
Valse indruk van typeveiligheid

Voorbeeld uit het leven

Negatief geval

In een aantal entiteiten kwamen velden toevallig overeen (bijvoorbeeld, User en Admin als {id: number, name: string}), wat leidde tot verwarring bij het werken met API-contracten.

Voordelen:

Minder code, makkelijker om nieuwe entiteiten uit te breiden

Nadelen:

Moeilijk om logische fouten te traceren die de compiler niet opmerkt

Positief geval

Gebruik van unieke "labels" symbolen en niet-standaard velden voor het onderscheiden van semantisch verschillende types met een gelijke structuur.