Esiste una programmazione orientata al protocollo?

Apple Inc. chiama i "protocolli" delle interfacce. Quando dicono "orientato al protocollo", intendono la programmazione utilizzando le interfacce anziché l'ereditarietà.

Da qui: link

Objective-C allows you to define protocols, which declare the methods expected to be used for a particular situation. Protocols are implemented in the classes conforming to the protocol.

Da Objective-C succintamente:

In Objective-C, a protocol is a group of methods that can be implemented by any class. Protocols are essentially the same as interfaces in C#, and they both have similar goals. They can be used as a pseudo-data type, which is useful for making sure that a dynamically-typed object can respond to a certain set of messages. And, because any class can “adopt” a protocol, they can be used to represent a shared API between completely unrelated classes.

Da Objective-C per i principianti assoluti:

Apple defines a protocol simply as a list of methods declarations, unattached to a class definition. The methods listed for protocols are suppose to be implemented by you.

Quindi, la programmazione orientata al protocollo è ciò che i programmatori Objective-C e Swift chiamano ciò che il resto di noi chiama favorire l'implementazione delle interfacce sull'estensione delle classi (ereditarietà).

Is it a new programming paradigm that has the potential to be as revolutionary as structured programming and abolish the dangerous "goto" of OOP?

No. Non è niente di nuovo, solo un nome diverso utilizzato nella comunità degli sviluppatori Apple. La composizione sull'ereditarietà ha enormi vantaggi sebbene siano stati ampiamente discussi in questo forum.

And since nothing is ever a silver bullet, what are the pitfalls of POP?

All'inizio non mi è venuto in mente, ma l'ho appena trovato in un forum in CodeRanch, post dell'utente Jim Yingst:

One disadvantage of interfaces is that one you publish them to other coders outside your own control, they represent a public commitment which can be difficult to change later. You don't know who else is using the interface and you don't know how, so you can't just add a new method to the interface without risking breaking the code of existing clients (if/when they upgrade). In comparison, if you'd used an abstract or concrete class, you could just add a new concrete method with no problems (usually).

It's possible to work around this by creating a new interface with extends or supplements the original one, and changing your concrete implementations to implement the new interface, instead of or in addition to the old one. That way you don't break existing client code. It's generally more work than adding a method to a class would be, but it's possible.

This disadvantage isn't a reason to abandon interfaces, but it is a reason to design your interfaces carefully, and think carefully before you publish a new interface in a new release. Spending some extra time designing things well now can save you many headaches later.

La grande differenza tra un protocollo Swift / Objective-C e un'interfaccia simile a Java è che i metodi nel primo possono avere implementazioni predefinite . Questo non è qualcosa che puoi fare con un'interfaccia Java. È quasi come avere classi astratte in C ++ e ereditarietà multipla.

POP è nuovo? Come già detto, anche Objective-C ha protocolli, quindi chiamarlo una "nuova cosa" è un po 'troppo lungo. Tuttavia, ciò che è nuovo di Swift è la capacità di implementare questi protocolli usando tipi di valore piuttosto che tipi di riferimento e questo è il grande affare che è stato presentato nella presentazione di Apple dove è stato introdotto il POP.

Non conoscevo il termine, essendo del mondo Microsoft. Ma dopo aver letto l'eccellente risposta di Tulains posso coprire la parte delle insidie.

Non è come se le POP (interfacce) siano migliori di OOP (eredità), entrambe hanno i loro scopi e punti di forza. Un'interfaccia è più flessibile e flessibile. L'ereditarietà ti lega al trunc di un particolare albero di classi, ma ti offre delle implementazioni gratuite delle basi, della struttura e della guida. Se l'ereditarietà viene eseguita correttamente, è difficile per il programmatore delle sottoclassi avvitare le cose.

Ma la ragione più importante dell'aumento di POP è probabilmente il mondo relativamente nuovo, distribuito, in rete con molti sviluppatori, che non si conoscono, potenzialmente lavorando allo stesso progetto. Si adatta al modello di una comunità in via di sviluppo e può attraversare i confini del linguaggio di processo e / o di programmazione (SOA). L'ereditarietà è significativa solo all'interno di un singolo progetto compilato dallo stesso compilatore. Il che non lo invalida, ha solo un dominio diverso.