Antwoord.

Achtergrond:

Protocollenabstrahering is geïntroduceerd in Swift als tegenhanger van de klassieke objectafgeleide erfelijkheid in OOP. Waar in Objective-C en andere OOP-talen de benadering van erfelijkheid "van algemeen naar specifiek" domineerde, heeft Swift vanaf het begin protocollen gepromoot als de belangrijkste manier om abstractie te bereiken, met de nadruk op samenstelling boven erfelijkheid.

Probleem:

Klassieke erfelijkheid veronderstelt een rigide hiërarchie: een boom van onderklassen met verplichte uitbreiding via override. Dit beperkt de flexibiliteit, leidt tot "fragiele" code, complexe refactoring en opblazing van basis superklassen. Bovendien ondersteunt Swift geen meervoudige klassenafleiding — wat betekent dat hergebruik van functionaliteit alleen mogelijk is via andere mechanismen.

Oplossing:

Protocollenabstrahering maakt het mogelijk om een "set eisen" te declareren die een type moet implementeren. Protocollen kunnen worden uitgebreid (extension) voor het inbrengen van gemeenschappelijke logica, wat ze dichterbij het concept van "mixins" brengt:

Codevoorbeeld:

protocol Drawable {
    func draw()
}

extension Drawable {
    func draw() {
        print("Standaardtekening")
    }
}

struct Circle: Drawable {}

let c = Circle()
c.draw() // Geeft "Standaardtekening" weer

Belangrijkste kenmerken:

Protocollen ondersteunen meervoudige compositie (meervoudige vereisten).
Creëren geen rigide hiërarchie — ze zijn gemakkelijker uit te breiden, breken de architectuur niet.
Kunnen werken met zowel value-types (struct/enum) als met class, wat niet mogelijk is bij erfelijkheid.

Vragen met een valstrik.

Wat is het verschil tussen extension van een protocol en normale implementatie in een klasse?

Uitbreiding van een protocol via extension voegt een default-implementatie toe alleen voor gevallen waarin de gebruiker deze methode niet in zijn type heeft geïmplementeerd. Als de methode expliciet in het type is geïmplementeerd, wordt precies die aangeroepen.

Voorbeeld:

protocol Demo {
    func foo()
}

extension Demo {
    func foo() { print("standaard") }
}

struct X: Demo {
    func foo() { print("aangepast") }
}

X().foo() // "aangepast"

Wat gebeurt er als je naar een type dat een protocol implementeert en zijn extensie als gegevens van het protocol verwijst?

Als een protocol een methode als verplicht (vereiste) declareert, wordt de implementatie van het specifieke type gebruikt, zelfs wanneer dit is omgezet naar het protocoltype. Als er echter een nieuwe (voorheen niet in het protocol gedeclareerde) eigenschap in de extensie is toegevoegd, zal deze alleen toegankelijk zijn via de extensie, niet via het protocoltype.

Kun je instances van verschillende struct-uren die hetzelfde protocol implementeren in een array opslaan?

Ja — dankzij "existentiële" types (bijvoorbeeld [Drawable]) kunnen heterogene collecties worden opgeslagen:

struct Tri: Drawable {
    func draw() { print("Driehoek") }
}
let arr: [Drawable] = [Circle(), Tri()]
arr.forEach { $0.draw() }

Veelvoorkomende fouten en antipatterns

Erfelijkheid van een zware superklasse voor een gemeenschappelijke interface in plaats van splitsen in protocollen
Overmatig gebruik van extensie zonder expliciete vereisten in protocollen
Poging om een protocol met associatedtype in een collectie op te slaan ([SomeProtocol]) — dit wordt niet ondersteund

Voorbeeld uit de praktijk

Negatief geval

In het bedrijf was er een basis superklasse Shape, waaruit alle vormen (Circle, Square, Polygon) werden afgeleid. De basisklasse groeide uit, omdat elke nieuwe vorm moest worden ondersteund via override. Het werd steeds moeilijker om het systeem uit te breiden — elke nieuwe type brak de ABI en dwong tot herschrijven van bestaande code.

Voordelen:

Snelle invoering van nieuwe gemeenschappelijke methoden via de basisklasse

Nadelen:

Monolithische hiërarchie met overmatige afhankelijkheden
Slechte herbruikbaarheid buiten de hiërarchie
Conflicten van override-methoden

Positief geval

Ze begonnen meerdere protocollen te gebruiken: Drawable, Colorable, Animatable. Nu kan elke vorm gemakkelijk zowel "animerend als gekleurd" zijn, zonder de andere structuren te wijzigen. Nieuwe functionaliteit kan worden toegevoegd via extensie.