Probabilmente chi ha gi\u00e0 sviluppato qualche programma in questo linguaggio l’ha gi\u00e0 incontrato, magari in quei fastidiosi “warning” che ci avvisano di non aver implementato tutti i metodi del protocollo tal dei tali, ma cos’\u00e8 in realt\u00e0 il costrutto protocol e a cosa serve?<\/p>\n
\n
![\"\"](\"http:\/\/www.devapp.it\/wordpress\/wp-content\/uploads\/2010\/02\/bannerIgnazioc.png\")
<\/a>\n<\/center>
\n<\/p>\n
Un po’ di storia<\/h4>\n
Il protocol (o interface<\/em> in java ) nasce per sopperire alla mancanza dell’ereditariet\u00e0 multipla, risolvendo il problema del diamante tagliando, di fatto, la gerarchia delle classi. I protocol<\/strong> rientrano in una aspetto della OOP chiamto polimorfismo<\/em>, ovvero la caratteristica che hanno gli oggetti trattati dalla OOP di poter “avere pi\u00f9 forme” o meglio di poter essere trattati non come un unico tipo, ma come il suo tipo specifico e tutti i tipi che lo precedono nella gerarchia delle classi, a differenza dei tipi primitivi che invece hanno per definizione un solo tipo.<\/p>\n Ad esempio un eggetto di tipo UILabel<\/em> possiamo vederlo sia come UILabel, ma \u00e8 anche una UIView<\/em>, un UIResponder<\/em> e un NSObject<\/em> e possiamo utilizzare su di lui tutti i metodi previsti da questi oggetti. Una variabile primitiva di tipo int<\/strong>, invece, \u00e8 solo un “int” e posso usarlo solo dove viene richiesto un int<\/em>.<\/p>\n Nota per gli smaliziati<\/strong>: lo so che il C non \u00e8 fortemente tipizzato quindi posso usare un “int” anche dove viene richiesto un “char”, ma non facciamo troppo i fiscali!<\/p>\n Questa struttra gerarchica \u00e8 molto versatile, ma alle volte il mondo reale non \u00e8 cos\u00ec ordinato come noi programmatori vorremo, quindi potrebbe nascere la necessit\u00e0 di ereditare da due classi differenti. Supponiamo che, dopo aver creato la classe “automobile” e la classe “barca”, vengano fuori delle auto anfibie come queste:<\/p>\n Se volessimo creare una classe per questo mezzo dovremmo esporre dei metodi specifici per l’automobile (frena) e dei metodi specifici per le barche (getta l’\u00e0ncora) e probabilmente saremmo tentati di creare una classe che eredita sia da “automobile” che da “barca” per evitare di riscrivere tutti i metodi e tutte le propriet\u00e0 di questi due mezzi.<\/p>\n Si presenta a questo punto un problema, noto appunto con il nome di “problema del diamante”. Supponiamo che le due classi “automobile” e “barca” abbiano entrambe il metodo “accelera”, magari perch\u00e8 entrambe ereditano dalla classe astratta “veicolo” dove \u00e8 specificato questo metodo, ma abbiamo due implementazioni diverse: una restituisce la velocit\u00e0 in kilometri e l’altra in nodi. Questo problema di chiama “del diamante” perch\u00e8 una sua schematizzazione potrebbe ricordare un diamante (ma non provate a regalarlo alla vostra donna!).<\/p>\n Per risolvere questo problema alcuni linguaggi come il java ed il nostro caro obj-c non permettono di implementare l’ereditariet\u00e0 multipla, eliminando il problema alla radice. Un “protocollo” \u00e8 in pratica un unico file .h (senza il .m) dove vengono elencati i metodi che lo costituiscono, lo possiamo pensare come una sorta di “contratto”.<\/p>\n Una classe pu\u00f2 implementare uno o pi\u00f9 protocolli, cos\u00ec facendo si impegna a fornire una implementazione ai metodi dei protocolli che ha implementato. C’\u00e8 un secondo aspetto che rende “protocol” un costrutto molto versatile ed \u00e8 il seguente. Se ci pensate bene l’unica cosa che vi interessa \u00e8 che gli oggetti da ordinare espongano un metodo come “(int)compareTo:(id)obj<\/strong>” quindi voi potreste dire al vostro cliente “se il tuo oggetto ha questo metodo allora puoi usare la mia funzione”.<\/p>\n Per ottenere questo comodissimo risultato bisogna proprio sfruttare il costrutto procol!<\/p>\n In java il costrutto “interface” definisce un tipo di dato,quindi se avete creato un interface di nome “comparable” nell’algoritmo potete lavorare direttamente con oggetti di tipo comparable. Purtroppo in obj-c la cosa non \u00e8 cos\u00ec comoda, il “protocol” non definisce un tipo di dato, quindi il massimo che possiamo fare \u00e8 lavorare con oggetti di tipo generico e specificare al compilatore che questi oggetti “preferiremmo” che implementassero il protocollo “comparable”.<\/p>\n In questo modo:<\/p>\n Purtroppo il compilatore si pu\u00f2 rendere conto solo di assegnazioni di tipo statico, quindi evidenzier\u00e0 solo di errori in fase di compilazione. Per essere certi che gli oggetti su cui lavoriamo implementano davvero il protocollo “comparable” dobbiamo utilizzare il seguente codice:<\/p>\n Per aiutare quindi il compilatore a segnalare anomalie nel codice \u00e8 sempre buona norma specificare quali protocolli abbiamo intenzione di implementare nelle nostre classi. La sinstassi per far questo \u00e8 la seguente<\/p>\n A questo punto dovrebbe essere chiaro cosa significa<\/p>\n in testa ai nostri controller delle tabelle…<\/p>\n non si tratta altro che di due protocolli, e con questo codice la classe si impegna a fornire una implementazione ai metodi del protocollo. Alla prossima!<\/p>\n Oggi torniamo a parlare di programmazione ad oggetti ed impareremo un’aspetto importante di questo paradigma di programmazione…<\/p>\n","protected":false},"author":53,"featured_media":5531,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[9],"tags":[5,549,550,546,547,548],"class_list":["post-5523","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-guide-teoriche","tag-objective-c","tag-polimorfismo","tag-problema-del-diamante","tag-protocol","tag-protocolli-objective-c","tag-teoria-programmazione-iphone"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/5523","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/users\/53"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/comments?post=5523"}],"version-history":[{"count":33,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/5523\/revisions"}],"predecessor-version":[{"id":6000,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/5523\/revisions\/6000"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/media\/5531"}],"wp:attachment":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/media?parent=5523"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/categories?post=5523"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/tags?post=5523"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nNon ci avete capito nulla? \u00e8 normale, non spaventatevi, tornate a leggere questa frase dopo aver letto tutto l’articolo, se allora vi sar\u00e0 pi\u00f9 chiara vorr\u00e0 dire che ho fatto bene il mio lavoro.<\/p>\n
\n![\"\"](\"http:\/\/www.devapp.it\/wordpress\/wp-content\/uploads\/2010\/12\/squba.jpg\")
<\/a>
\n<\/center><\/p>\n
\nSe la nostra vettura anfibia eredita da entrambe le classi, e non effettua l’override del metodo “accelera” quando verr\u00e0 invocato questo metodo quale codice verr\u00e0 eseguito? Quello della classe “auto” o della classe “barca”?<\/p>\n
\n![\"\"](\"http:\/\/www.devapp.it\/wordpress\/wp-content\/uploads\/2010\/12\/Untitleddrawing.png\")
<\/a>
\n<\/center><\/p>\n
\nPurtroppo per\u00f2 i casi come la macchina anfibia nella realt\u00e0 sono pi\u00f9 comuni di quanto si pensi e, soprattutto se abbiamo sbagliato a creare la nostra gerarchia delle classi, viene proprio la voglia di fare copia\/incolla di codice con tutti i problemi che conosciamo.
\nPer venirci incontro \u00e8 stato creato il costrutto “interface” in java e “protocol” in obj-c che, anche se non risolve appieno il problema, almeno ci offre una mezza soluzione.<\/p>\nProtocol in pratica<\/h4>\n
\r\n#import \r\n\r\n@protocol NOME_PROTOCOLLO\r\n\r\n- (void)primoMetodo;\r\n- (void)secondoMetodo;\r\n....\r\n@end\r\n<\/pre>\n
\nQuesto sembrerebbe non aver risolto il nostro problema, perch\u00e8 potremmo trovarci costretti a riscrivere due volte la stessa implementazione di un metodo di un protocollo in due classi separate che lo implementano, ma in compenso ci offre la possibili\u00e0 di definire delle relazioni tra classi che non stanno sullo stesso ramo dell’albero delle gerarchie, per questo si dice che i protocol “tagliano l’albero delle gerarchie”.
\nIn questo caso il “problema del diamante” non si pu\u00f2 presentare perch\u00e9 nei protocolli non ci sono metodi implementati, ma solo le loro “signatures”<\/p>\nProtocol come tipo di dato<\/h4>\n
\nSupponiate di aver scritto il miglior algoritmo di ordinamento basato su confronti, un algoritmo fantastico che per ordinare n<\/em> interi ci metta meno di nlogn<\/em> tempo e lo vogliate vendere. Che tipi di dati ordinerebbe la vostra funzione? interi? stringhe? automobili?
\nOvviamente se riusciste a fare una funzione generica che ordina qualsiasi<\/em> tipo di dato sareste sicuri di venderne milioni di copie..ma come fare?<\/p>\n\r\nUIView < NOME_PROTOCOLLO > *target;\r\n<\/pre>\n
\r\nif ([target conformsToProtocol:@protocol(NOME_PROTOCOLLO)] == YES ) {\r\n \/\/do something.\r\n}\r\n<\/pre>\nImplementare un protocollo<\/h4>\n
\r\n\/\/nel file .h della dichiarazione della classe\r\n@interface NOME_CLASSE : NOME_SUPERCLASSE < NOME_PROTOCOLLO > {\r\n\tUIColor *baseColor;\r\n}\r\n<\/pre>\n\r\n< UITableViewDelegate , UITableViewDataSource >\r\n<\/pre>\n
\nSe le implementazioni sono parziali il compilatore segnaler\u00e0 l’errore con un warning.<\/p>\n
\n<\/a>
\n<\/center><\/p>\n","protected":false},"excerpt":{"rendered":"