Quando si parla di linguaggio di programmazione Objective-C, abbreviato spesso con Obj-c, una tra le prime informazioni che viene data \u00e8 che l’intero linguaggio \u00e8 un superset del linguaggio standard C. Ci\u00f2 significa in breve che all’interno di un programma obj-c potete scrivere tutto il codice C che vi pare, questo funzioner\u00e0 perfettamente. Questo permette, tra l’altro, di poter riutilizzare moltissime librerie “classiche” scritte in C all’interno dei nostri programmi, come le socket BSD e molto altro.<\/p>\n
Obj-C ha un’altra particolarit\u00e0 degna di nota, che va sotto il nome di Binding Dinamico (wikipedia<\/a>). Il Binding \u00e8 il processo che viene eseguito dal compilatore o dall’interprete che associa una particolare parte di codice al nome di una funzione. \u00c8, in altri termini, quel processo che ci permette di invocare una parte di codice utilizzando il nome della funzione associata.<\/p>\n In Obj-C questo processo viene eseguito a runtime<\/em>, viene cio\u00e8 fatto durante l’esecuzione del programma stesso e prende il nome di Binding Dinamico<\/i>, mentre negli altri linguaggi viene effettuato a\u00a0compile time<\/em>, ovvero durante la fase di compilazione. In quest’ultimo caso si chiama\u00a0Binding statico.<\/em><\/p>\n Il binding \u00e8 un argomento piuttosto tecnico ma per capire il concetto alla base vediamo due esempi in C, in questo primo programma viene semplicemente richiamata la funzione doppio() quindi niente di particolare. (eseguite il codice qui: http:\/\/ideone.com\/l4KIYx<\/a>)<\/p>\n In questo caso il compilatore “semplicemente” sostituisce alla chiamata alla funzione doppio() il suo indirizzo di memoria.<\/p>\n In questo secondo esempio abbiamo invece un puntatore a funzione, che viene assegnato alla funzione doppio() o triplo() a seconda se il valore \u00e8 pari o dispari. (esegui il codice qui: http:\/\/ideone.com\/IkYy9B<\/a>)<\/p>\n Quello che \u00a0si vede in questo esempio \u00e8 che usando i puntatori a funzione possiamo, a\u00a0runtime<\/em>, switchare il comportamento della funzione tra una implementazione o un’altra. Possiamo, cio\u00e8, con lo stesso nome invocare parti di codice completamente distinte.<\/p>\n Questo ragionamento un po’ articolato \u00e8 indispensabile se si vuole scrivere codice ad oggetti con un linguaggio che nativamente non \u00e8 ad oggetti ed \u00e8 infatti alla base del funzionamento dell’Obj-c.<\/p>\n In Obj-c tutta la parte che si occupa del binding \u00e8 inserita in una libreria che si chiama “Objective-C runtime” e della quale potete leggere qui (http:\/\/goo.gl\/Tc2y3j<\/a>) la documentazione e qui (http:\/\/goo.gl\/fd1U6A<\/a>) la programming guide.<\/p>\n Questa libreria \u00e8 molto importante anche per altri argomenti che vanno oltre lo scopo di questo articolo, come l’introspection e la metaprogrammazione.<\/p>\n Cosa succede dietro le quinte del linguaggio Obj-C quando viene inviato un messaggio? Cosa fa di preciso una semplice riga come questa?<\/p>\n Il compilatore traduce questa riga in puro C e traducendo l’invio del messaggio in una chiamata alla funzione objc_msgSend() il cui prototipo \u00e8 questo:<\/p>\n Questa “traduzione” produce questa riga di codice<\/p>\n Per trovare la corretta implementazione del selector messageName l’obj-c runtime analizza la mappa dei metodi dell’oggetto anobject. Questa mappa contiene da una parte il selector (che \u00e8 una struct C) e dall’altra un puntatore a funzione. La tecnica dello swizzling constite nell’invertire a runtime l’implementazione di due metodi ed \u00e8 quindi possibile soltanto negli ambienti con il binding dinamico. Create un progetto xcode di qualsiasi tipo, in questo caso io ho utilizzato “console application” perch\u00e9 non ho bisogno di alcuna interfaccia per questo esercizio.<\/p>\n All’interno del progetto create una classe con due metodi:<\/p>\n Se avete creato un progetto di tipo console andate a modificare il file main, viceversa utilizzate il vostro delegate. l’output sar\u00e0 senza grosse sorprese:<\/p>\n Adesso per\u00f2 facciamo la magia! usiamo due metodi dell’obj-c runtime per mischiare le carte \ud83d\ude42<\/p>\n Primo passo importiamo la libreria con un:<\/p>\n Poi aggiungiamo sotto il codice scritto poco fa il codice per scambiare le due implementazioni:<\/p>\n a questo punto possiamo ri-verifica il comportamento della nostra classe, stampando nuovamente le righe di log. Ecco il codice completo della mia funzione main():<\/p>\n Adesso l’output sar\u00e0 questo:<\/p>\n dove si nota chiaramente che le ultime due invocazioni hanno cambiato il loro comportamento.<\/p>\n Conoscere e utilizzare in modo produttivo l’obj-c runtime pu\u00f2 aiutare molto nello sviluppo di applicazioni complesse, ma occhio a come viene usato! Invertire l’implementazione di alcuni metodi o agire cos\u00ec in profondit\u00e0 pu\u00f2 portare ad avere un codice dal comportamento imprevedibile e quindi impossibile da debuggare, quindi usatelo solo quando strettamente necessario.<\/p>\n Chi conosce l’argomento UnitTest (qui<\/a>\u00a0una introduzione) probabilmente utilizza anche qualche framework per gestire i mock object, come OCMock<\/a> oppure OCMokito<\/a>. Alla base del funzionamento di questi framework c’\u00e8 proprio l’obj-c runtime senza il quale non si potrebbero compiere tutte le modifiche a basso livello necessarie per generare i mock object.<\/p>\nIl binding in C<\/h2>\n
\r\n#include \r\n\r\nint doppio(int n) {\r\n\treturn n * 2;\r\n}\r\n\r\nint main(void) {\r\n\tint input = 42;\r\n\tint risultato = doppio(input);\r\n\r\n\tprintf(\"Il risultato: %d\", risultato);\r\n\treturn 0;\r\n}<\/pre>\n#include \r\n\r\nint doppio(int n) {\r\n\treturn n * 2;\r\n}\r\nint triplo (int n) {\r\n\treturn n * 3;\r\n}\r\n\r\nint main(void) {\r\n\tint k = 3;\r\n\tint risultato;\r\n\r\n\tint (*func)(int k);\r\n\r\n\tif (k % 2 == 0) {\r\n\t\tfunc = doppio;\r\n\t} else {\r\n\t\tfunc = triplo;\r\n\t}\r\n\r\n\trisultato = func(k);\r\n\tprintf(\"Il risultato: %d\", risultato);\r\n\r\n\treturn 0;\r\n}<\/pre>\nObjc_msgsend<\/h2>\n
\r\nid returnvalue = [anobject messageName:parameter];\r\n<\/pre>\n
\r\nid objc_msgSend(id theReceiver, SEL theSelector, ...)\r\n<\/pre>\n
\r\nid returnvalue = objc_msgsend(anobject, @selector(messageName:), parameter);\r\n<\/pre>\n
\nSe il runtime non trova il selector all’interno di questa mappa allora segue il puntatore “isa” dell’oggetto per risalire nella gerarchia delle classi.
\nSe per esempio invochiamo il metodo alloc sulla classe NSString, nella sua mappa non ci sar\u00e0 alcuna entry per questo selector e in runtime proseguir\u00e0 nella ricerca sulla classe NSObject che \u00e8 l’immediata superclass di NSString.<\/p>\nSwizzling<\/h2>\n
\nObj-c si presta bene a questo tipo di tecnica che, anche se \u00e8 un po’ “oscura”, si pu\u00f2 rivelare molto utile in certi casi.<\/p>\n\r\n\/\/file Dog.h\r\n#import \r\n\r\n@interface Dog : NSObject\r\n-(NSString *)bark;\r\n-(NSString *)growl;\r\n@end\r\n\r\n\/\/file Dog.m\r\n#import \"Dog.h\"\r\n\r\n@implementation Dog\r\n-(NSString *)bark {\r\n return @\"WOOF\";\r\n}\r\n\r\n-(NSString *)growl {\r\n return @\"GRRRR\";\r\n}\r\n@end\r\n<\/pre>\n
\nLa prima cosa da fare \u00e8 verificare il comportamento della nostra classe, quindi scriviamo un piccolo esempio all’interno del main<\/p>\n\r\nint main(int argc, const char * argv[])\r\n{\r\n\r\n @autoreleasepool {\r\n Dog *dog1 = [[Dog alloc] init];\r\n NSLog(@\"Bark: %@\", [dog1 bark]);\r\n NSLog(@\"Growl: %@\", [dog1 growl]);\r\n}\r\n}\r\n<\/pre>\n\r\n2013-09-07 09:52:40.646 learnSwizzling[95797:303] Bark: WOOF\r\n2013-09-07 09:52:40.649 learnSwizzling[95797:303] Growl: GRRRR\r\n<\/pre>\n
#import<\/pre>\n
\r\nMethod original, swizzled;\r\noriginal = class_getInstanceMethod([Dog class], @selector(bark));\r\nswizzled = class_getInstanceMethod([Dog class], @selector(growl));\r\nmethod_exchangeImplementations(original, swizzled);\r\n<\/pre>\n
\r\n#import \r\n#import \r\n#import \"Dog.h\"\r\n\r\nint main(int argc, const char * argv[])\r\n{\r\n\r\n @autoreleasepool {\r\n Dog *dog1 = [[Dog alloc] init];\r\n NSLog(@\"Bark: %@\", [dog1 bark]);\r\n NSLog(@\"Growl: %@\", [dog1 growl]);\r\n\r\n Method original, swizzled;\r\n original = class_getInstanceMethod([Dog class], @selector(bark));\r\n swizzled = class_getInstanceMethod([Dog class], @selector(growl));\r\n method_exchangeImplementations(original, swizzled);\r\n\r\n NSLog(@\"Bark: %@\", [dog1 bark]);\r\n NSLog(@\"Growl: %@\", [dog1 growl]);\r\n }\r\n return 0;\r\n}\r\n<\/pre>\n\r\n2013-09-07 09:52:40.646 learnSwizzling[95797:303] Bark: WOOF\r\n2013-09-07 09:52:40.649 learnSwizzling[95797:303] Growl: GRRRR\r\n2013-09-07 09:52:40.650 learnSwizzling[95797:303] Bark: GRRRR\r\n2013-09-07 09:52:40.651 learnSwizzling[95797:303] Growl: WOOF\r\n<\/pre>\n
Conclusioni<\/h2>\n