Risposta.

Storia della questione:

L'astrazione dei protocolli è emersa in Swift in contrapposizione all'ereditarietà classica degli oggetti in OOP. Se in Objective-C e in altri linguaggi OOP dominava l'approccio dell'ereditarietà "dal generale al particolare", Swift ha sin dall'inizio promosso i protocolli come il modo principale per raggiungere l'astrazione, sottolineando la composizione sopra l'ereditarietà.

Problema:

L'ereditarietà classica implica una gerarchia rigida: un albero di sottoclassi con estensioni obbligatorie tramite override. Ciò limita la flessibilità, porta a codice "fragile", rendendo difficile il refactoring e gonfiando le classi base. Inoltre, Swift non supporta l'ereditarietà multipla delle classi, il che significa che il riutilizzo della funzionalità è possibile solo attraverso altri meccanismi.

Soluzione:

L'astrazione dei protocolli consente di dichiarare un "insieme di requisiti" che un tipo deve implementare. I protocolli possono essere estesi (extension) per iniettare logica comune, avvicinandoli al concetto di "mixins":

Esempio di codice:

protocol Drawable {
    func draw()
}

extension Drawable {
    func draw() {
        print("Disegno predefinito")
    }
}

struct Circle: Drawable {}

let c = Circle()
c.draw() // Stampa "Disegno predefinito"

Caratteristiche principali:

I protocolli supportano la composizione multipla (richieste multiple).
Non creano gerarchie rigide — più facile da estendere, non rompono l'architettura.
Possono lavorare sia con tipi value (struct/enum) che con class, il che non è possibile con l'ereditarietà.

Domande trabocchetto.

Qual è la differenza tra l'estensione di un protocollo e l'implementazione normale in una classe?

L'estensione di un protocollo tramite extension aggiunge un'implementazione predefinita solo nei casi in cui l'utente non ha implementato quel metodo nel proprio tipo. Se il metodo è implementato esplicitamente nel tipo, viene chiamato proprio quello.

Esempio:

protocol Demo {
    func foo()
}

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

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

X().foo() // "personalizzato"

Cosa succede se ci si riferisce a un tipo che implementa un protocollo e la sua estensione come dati del protocollo?

Se un protocollo dichiara un metodo come obbligatorio (requisito), viene utilizzata l'implementazione del tipo specifico anche quando viene convertito al tipo del protocollo. Tuttavia, se nell'estensione viene aggiunta una nuova proprietà (non precedentemente dichiarata nel protocollo), essa sarà accessibile solo tramite l'estensione, non tramite il tipo del protocollo.

È possibile memorizzare in un array istanze di diversi struct che implementano un unico protocollo?

Sì — grazie ai "tipi esistenziali" (ad esempio, [Drawable]) è possibile memorizzare collezioni eterogenee:

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

Errori comuni e anti-pattern

Ereditarietà da una superclasse pesante per un'interfaccia comune invece di separarsi in protocolli
Uso eccessivo di extension senza requisiti espliciti nei protocolli
Tentativo di memorizzare un protocollo con associatedtype in una collezione ([SomeProtocol]) — ciò non è supportato

Esempio della vita reale

Caso negativo

Nell'azienda c'era una superclasse base Shape, dalla quale ereditavano tutte le figure (Circle, Square, Polygon). La classe base si gonfiava, perché ogni nuova figura doveva essere supportata tramite override. Espandere il sistema diventava sempre più difficile — ogni nuovo tipo rompeva l'ABI e costringeva a riscrivere codice esistente.

Vantaggi:

Implementazione rapida di nuovi metodi comuni tramite la classe base

Svantaggi:

Gerarchia monolitica con dipendenze eccessive
Scarsa riutilizzabilità al di fuori della gerarchia
Collisioni nei metodi override

Caso positivo

Si è iniziato a utilizzare più protocolli: Drawable, Colorable, Animatable. Ora ogni figura può essere facilmente resa "animata e colorata" senza modificare le altre strutture. Nuove funzionalità vengono aggiunte tramite extension.