31. oktober 2026
Introduktion
En af de nyere udviklinger i AL-sproget er muligheden for at definere standardimplementeringer direkte i interfaces. Det ændrer, hvordan interfaces kan udvikles over tid uden at tvinge alle eksisterende implementorer til øjeblikkeligt at tilpasse deres kode.
Hvad er ændret?
Tidligere var AL‑interfaces rene kontrakter: nye metoder i et interface krævede, at alle implementerende objekter fik opdateret kode. Med standardmetoder kan interface‑forfatteren levere en standardimplementering, så eksisterende implementorer fortsat fungerer, mens nye funktioner introduceres gradvist.
Samtidig introduceres værktøjer som RequiredPending og analyzer-regler, der hjælper med at planlægge nødvendige ændringer uden at bryde eksisterende udvidelser med det samme. Det skaber et mere kontrolleret evolutionsforløb for API'er.
Fordele og konsekvenser
- Mindre risiko for pludselige breaking changes ved opgradering.
- Hurtigere mulighed for at tilføje funktionalitet i baseline‑interface uden at tvinge alle partnere til øjeblikkelig opdatering.
- Kræver dog, at teams bruger analyzer-regler aktivt og tester implementeringer mod både gamle og nye forventninger.
For ISV'er betyder det, at de kan indføre nye kapaciteter mere fleksibelt, men også at de bør overvåge de analyzer-advarsler, som angiver nødvendige ændringer over tid.
Hvad betyder det for dig?
For danske udviklingsteams og ISV'er giver standardmetoder i interfaces større frihed til at udvikle platformen. Praktisk set bør I:
- Opdatere jeres build‑analyser og CI‑pipelines til at fange analyzer‑warnings.
- Planlægge en migrationsstrategi for, hvornår I opdaterer egne implementeringer til at bruge nye interface-metoder.
- Benytte testmatrixer, der dækker både tidligere og nye interface‑adfærd for at undgå regressionsfejl.
I korte træk: bedre kontrol over API‑evolution, men krav om disciplin i test og analysetracking for at undgå uventede problemer ved opgraderinger.
Kilde: YZHumS