Confronta il protocollo in Swift vs Interface in Java


149

Sto seguendo il tutorial iOS dalla pagina degli sviluppatori Apple .

Mi sembra che protocole interfacequasi hanno la stessa funzionalità.

  • Ci sono differenze tra i due?

  • il diverso utilizzo nel progetto?

aggiornato

, ho letto il link sopra e non sono ancora sicuro di quali siano le differenze e l'utilizzo tra protocole interface. Quando faccio una domanda come questa, vorrei vedere una semplice spiegazione sull'argomento. A volte potrebbe essere difficile ottenere tutto dalla documentazione.


1
I protocolli in Swift e le interfacce in Java sono gli stessi concetti. Vedi qui
Vivek Molkar,

69
Penso che domande come questa sulle differenze tra le lingue siano davvero utili per comprendere le caratteristiche del linguaggio. E non penso che portino a risposte supposte non necessarie né a cui sia molto facile trovare la risposta nella documentazione. Quindi non credo che i voti negativi su questa domanda siano giustificati.
Lii,

1
Ecco un paio di punti critici del mondo reale sulle interfacce Java - stackoverflow.com/a/41143492/294884 - sarebbe la chiave per chiunque sia nuovo con Swift, provando Java
Fattie

Nella direzione opposta, è woprth ricordando che l'intera ragion d'essere di Swift è che è per la "programmazione orientata al protocollo". Fai tutto con "estensioni di protocollo" in Swift onnipresente. Ad esempio, ecco un problema sottile su Swift (ovvero: "sulle estensioni del protocollo") che illustra alcuni dei problemi.
Fattie,

2
In Swift, anziché nelle interfacce, viene utilizzato il nome del protocollo perché nei file di intestazione C obiettivo (duplicati inutili) da C sono chiamati interfacce
Alex78191,

Risposte:


117

Essenzialmente i protocolli sono molto simili alle interfacce Java tranne:

  • I protocolli rapidi possono anche specificare proprietà che devono essere implementate (ad es. Campi)
  • I protocolli rapidi devono gestire il valore / riferimento attraverso l'uso della parola chiave mutante (poiché i protocolli possono essere implementati da strutture e classi)
  • puoi combinare i protocolli in qualsiasi momento con la parola chiave protocol <>. Ad esempio, dichiarando un parametro di funzione che deve aderire al protocollo A e B come:

.

func foo ( var1 : protocol<A, B> ){}

Queste sono le differenze immediatamente evidenti per uno sviluppatore Java (o almeno quello che ho notato finora).


13
" il protocollo <> parola chiave ": è davvero fantastico! Penso che questo sia ciò che viene chiamato un tipo di intersezione nella comunità della teoria dei sistemi di tipo. In Java puoi avere tali tipi solo per parametri di tipo con limiti multipli. Questo documento suggerisce di introdurli in Java come tipo di prima classe, con sintassi per denotarli.
Lii,

7
Bel riassunto. Un paio di funzionalità più importanti: i protocolli Swift possono anche specificare requisiti di tipo associati, ad esempio un tipo di raccolta ha un tipo di indice associato oppure i metodi di confronto di un tipo comparabile richiedono un parametro dello stesso tipo. E in Swift 2.0, le estensioni di protocollo possono aggiungere funzionalità effettive ai tipi che soddisfano i requisiti di un protocollo.
rickster,

2
Anche @rickster Java 8 può aggiungere l'implementazione a un'interfaccia taggando un metodo con la default parola chiave . Vedi il tutorial Oracle .
Basil Bourque,

5
La parola chiave protocollo <> è stata ora rimossa a favore della e commerciale. Quindi puoi scrivere: let c: A & B
Paul Robinson

2
In Swift, anziché nelle interfacce, viene utilizzato il nome del protocollo perché nei file di intestazione C obiettivo (duplicati inutili) da C sono chiamati interfacce
Alex78191,

33

A complemento della risposta di Thomas Schar. La magia del protocollo Swift proviene dall'estensione.

  • I protocolli Swift possono ottenere implementazioni tramite l'estensione (Swift
    2). L'interfaccia Java 8 può avere implementazioni predefinite, ma non può essere eseguita "retroattivamente".
  • In Swift, puoi "retroattivamente" aggiungere i requisiti del protocollo (e le
    sue implementazioni se necessario) a qualsiasi classe o struttura.
  • I protocolli rapidi non seguono il modello di personalizzazione generico (cioè <..>), ma uno schema typealias (cioè tipi associati). Può essere fonte di confusione all'inizio, ma
    in alcuni casi può evitare la "cecità della parentesi angolare".
  • Swift ha una corrispondenza del modello di tipo avanzata, che consente di essere molto specifici su dove e come vengono applicati i requisiti e le estensioni del protocollo. Può essere fonte di confusione quando proviene da Java, ma ha molta potenza.
  • Un protocollo rapido può essere composto per una proprietà / parametro (es. Celebratore: protocollo)

Una cosa che mi ha fatto grattare la testa per un paio d'ore è che non tutti i protocolli possono essere usati come tipi di proprietà. Ad esempio, se si dispone di un protocollo con typealias, non è possibile utilizzarlo direttamente come un tipo di proprietà (ha senso se ci si pensa, ma provenendo da Java vogliamo davvero avere una proprietà come userDao: IDao).


7
Inoltre i protocolli Swift possono avere membri opzionali, a differenza delle interfacce Java.
eyeApps LLC,

4
Un punto secondario che emerge sempre in Swift è che non ci sono (ridicolmente) funzioni astratte, quindi vai semplicemente "stampa, hai dimenticato questo!" ... stackoverflow.com/a/24111430/294884
Fattie

@Fattie. È possibile utilizzare la parola chiave "richiesto" su una funzione per specificare che richiede un'implementazione della sottoclasse. Quindi, davvero, più come un'ignoranza minore che un punto reale.
Dirk Bester,

@DirkBester - evviva - aspetta, stai parlando con gli inizializzatori ??
Fattie il

Ancora @DirkBester Potrei avere un po 'di confusione ma non si può usare requiredprima di una funzione in un protocollo, si ottiene solo 'required' may only be used on 'init' declarations...
Fattie
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.