Programmazione contro un protocollo in Objective-C

Il TDD non è molto popolare nel mondo ObjC. Guarda alcune delle librerie ufficiali dell'SDK di Apple e troverai dei pattern che farebbero disgustare i sostenitori di TDD (c'è un lotto di singleton nell'SDK di iOS, ed è un modello che funziona molto bene con ObjC). I test unitari in generale non sono così popolari, il che spiega perché la suite ufficiale di test unitari sia un'edizione relativamente recente di Xcode e perché sia ancora di terza categoria. La filosofia ObjC sembra essere:

"Don't make your code more complicated in order to write tests: simple code is easier to debug."

Questo sicuramente farà tremare i ragazzi del TDD, ma è l'approccio che ho notato negli sviluppatori di ObjC.

ObjC adotta un approccio più pragmatico ai protocolli rispetto agli sviluppatori Java per le interfacce ("ogni classe deve avere un'interfaccia e un'implementazione, per ogni evenienza!"):

• Se conosci hai bisogno di più classi con la stessa interfaccia e vuoi l'aiuto del compilatore, puoi creare un protocollo.
• Se conosci hai bisogno di più classi con la stessa interfaccia ma non ti interessa il supporto del compilatore, puoi usare "protocolli informali" (dai un'occhiata a come gestire dati da un oggetto GKSession : si implementa un metodo, non un protocollo).
• Se probabilmente utilizzerai solo una classe, usa semplicemente la classe e dimentica i protocolli.

Questo è il motivo per cui tendi a vedere i protocolli usati in congiunzione con i delegati: tendono ad essere gli unici posti in cui creerai più di una classe per implementare le funzionalità necessarie, specialmente perché il pattern dei delegati è così pervasivo. Altre lingue tendono a richiedere la sottoclasse e l'override o l'implementazione di un'interfaccia per fornire funzionalità aggiuntive; ObjC tende invece ad usare i delegati.

Il fatto che ObjC sia dinamico elimina gran parte della necessità di protocolli / interfacce. Gli sviluppatori Java, C ++ e C # impiegano molto tempo a cercare di categorizzare e digitare tutto il più accuratamente possibile, generando moltitudini di interfacce e classi. Questo semplicemente non è necessario in un linguaggio dinamico (ed è uno dei motivi per cui sono così felice di essere passato da C # a ObjC: posso passare il mio tempo a risolvere i problemi invece di descrivere le gerarchie di tipi).

ObjC è dinamico e supporta digitazione anatra , quindi se un oggetto implementa un metodo "ciarlatano" puoi chiamare quel metodo senza conformarsi esplicitamente al protocollo "Duck"; puoi persino identificare se l'oggetto implementa il metodo prima di chiamarlo grazie alle eccellenti capacità di metaprogrammazione di ObjC.

I principi SOLID non necessariamente si applicano in qualsiasi contesto, indipendentemente dalla tecnologia o dal linguaggio di programmazione. Molti sviluppatori scelgono di rispettarli però, ed è certamente possibile farlo in Objective-C.

Se sei interessato a vedere il primo Objective-C di prova, dai un'occhiata a BrowseOverflow : è un test completo -app sviluppata che utilizza UIKit e servizi di rete. In realtà l'ho scritto come codice di esempio per Sviluppo iOS Test-driven , ma se sei a tuo agio con i principi puoi semplicemente guardare il codice. Puoi vedere che anche se il codice è stato testato, non è ricco di protocolli.

Una ragione è "digitazione anatra". Objective-C, come Smalltalk prima e dopo Ruby, non si preoccupa di che tipo è un oggetto, semplicemente manda messaggi. Il sistema di sicurezza del tipo è interamente limitato al controllo del compilatore. È quindi possibile digitare una variabile nel modo specifico che si desidera e ancora (a volte con un casting) fornire un tipo diverso in fase di esecuzione. Finché entrambi i tipi rispondono ai messaggi passati nel tuo codice, tutto funziona. Puoi vedere che i test di BrowseOverflow lo usano per passare i falsi test, anche per le variabili che non sono state digitate usando i protocolli.

Infatti negli Objective-C storici e Smalltalk (e nel moderno Ruby) molti oggetti collaborativi non sono affatto digitati: in Objective-C il tipo id significa "qualsiasi oggetto". Questo è meno comune ora in ObjC, ma un sacco di codice framework di Apple è abbastanza vecchio per essere stato in giro quando questa era la norma. Noterai che i framework più recenti e le API più recenti su framework esistenti utilizzano tipi di protocollo e di tipizzazione più stringenti per i collaboratori non delegati.

Is there a reason why an ObjC developer would only use protocols for delegates?

Scelta personale. Non c'è alcun motivo tecnico di base per seguire questo approccio.

Does SOLID programming apply for ObjC?

Sì. O meglio, può farlo, e molti sviluppatori scelgono di seguire i principi SOLID.