{"id":1199,"date":"2009-12-11T11:50:54","date_gmt":"2009-12-11T10:50:54","guid":{"rendered":"http:\/\/www.devapp.it\/wordpress\/?p=1199"},"modified":"2010-04-27T13:53:05","modified_gmt":"2010-04-27T11:53:05","slug":"l009-programmazione-orientata-agli-oggetti-oop","status":"publish","type":"post","link":"https:\/\/www.devapp.it\/wordpress\/l009-programmazione-orientata-agli-oggetti-oop\/","title":{"rendered":"L#009 – Programmazione Orientata agli Oggetti (OOP)"},"content":{"rendered":"

Con l’articolo di oggi non intendo scrivere un trattato sulla teoria della programmazione ad oggetti, non ne sarei capace e gli scaffali delle librerie sono pieni di libri su questo argomento\u2026vorrei invece, con l’aiuto di qualche esempio, far vedere come i pilastri della OOP vengono implementati in objc e come la conoscenza di questi concetti basilari sia indispensabile per interpretare correttamente le guide fornite da Apple.
\nMa quali sono questi pilastri della OOP? Sono l’ereditariet\u00e0<\/em>, l’incapsulamento<\/em> ed il polimorfismo<\/em>, vediamo brevemente cosa sono e come applicarli creando una nostra classe inventata, la classe “persona<\/em>“.<\/p>\n

Creiamo una nuova classe cliccando sul men\u00f9 file-> new file e selezionando dalla categoria “cocoa touch class” l’icona obiettive-c class. Notiamo la voce “subclass of: NSObject” questo significa che la nostra classe erediter\u00e0 direttamente da NSObject, la madre di tutte le classi, se non \u00e8 chiaro lo sar\u00e0 pi\u00f9 avanti quando parleremo di ereditariet\u00e0.<\/p>\n

Diamo un nome significativo (“fraction<\/em>“) e clicchiamo su ok. I file creati hanno questa sintassi, io li ho arricchiti con due variabili di istanza e 5 metodi:<\/p>\n

\r\n\/\/file fraction.h\r\n@interface Fraction: NSObject {\r\n    int numerator;\r\n    int denominator;\r\n}\r\n-(void) print;\r\n-(void) setNumerator: (int) n;\r\n-(void) setDenominator: (int) d;\r\n-(int) numerator;\r\n-(int) denominator;\r\n@end<\/pre>\n
\r\n\/\/file fraction.m\r\n@implementation Fraction\r\n-(void) print {\r\n    printf( \"%i\/%i\", numerator, denominator );\r\n}\r\n\r\n-(void) setNumerator: (int) n {\r\n    numerator = n;\r\n}\r\n\r\n-(void) setDenominator: (int) d {\r\n   if (d!=0)\r\n       denominator = d;\r\n}\r\n\r\n-(int) denominator {\r\n    return denominator;\r\n}\r\n\r\n-(int) numerator {\r\n    return numerator;\r\n}\r\n@end<\/pre>\n
La suddivisione in due file .h e .m ha il solo scopo di separare formalmente la “descrizione<\/em>” di una classe dalla sua implementazione. La “descrizione” di una classe in OOP si chiama “interfaccia<\/strong>” ed \u00e8 costituita dall’elenco dei metodi e, se ci sono, l’elenco delle variabili di istanza. Questo \u00e8 tutto quello che serve ad un ipotetico utilizzatore della nostra classe, il quale la potr\u00e0 utilizzare come una semplice blackbox<\/em> che esegue quanto specificato nell’interfaccia, senza curarsi dell’implementazione<\/strong>. Nel nostro caso l’utilizzatore della nostra classe non avr\u00e0 accesso diretto alle variabili numerator<\/em> e denumerator<\/em> se non utilizzando gli appositi metodi setNumerator<\/em> e setDenumerator<\/em>. Questo ci ha dato la possibilit\u00e0 di inserire un controllo sul valore del denominatore che sarebbe stato pressocch\u00e8 impossibile altrimenti.<\/p>\n
Questo \u00e8 il primo pilastro della OOP, ovvero l’incapsulamento<\/strong>, l’arte del nascondere l’implementazione.<\/em> In realt\u00e0 la faccenda \u00e8 un p\u00f2 pi\u00f9 complicata di cos\u00ec, perch\u00e8 la presenza di opportuni modificatori (@public, @private , @protected etc) permettono di variare la visibilit\u00e0 delle variabili di istanza e dei metodi, ma al momento ci accontentiamo di sapere che fornire una corretta interfaccia alla classe e nascondere l’implementazione assicura versatilit\u00e0 e possibilit\u00e0 di riutizzo del codice.<\/p>\n
Dopo il nome della classe ed i due punti troviamo il nome della superclasse, in questo caso NSObject. Ma a che serve specificare una superclasse? Serve, banalmente, a sfruttare il lavoro gi\u00e0 svolto. Supponiamo di aver gi\u00e0 creato e testato la classe “persona” con tutti i suoi metodi quando ci commissionano un programma\u00a0 per gestire il personale di un ufficio, avremo probabilmente bisogno di aggiungere alcune propriet\u00e0 alla classe persona, per esempio “reparto” oppure “livello” etc. <\/p>\n
In questo caso entra in gioco l’ereditariet\u00e0<\/strong>, perch\u00e8 piuttosto che creare ex novo la classe impiegato<\/em> potremo semplicemente specificare che la sua superclasse \u00e8 la classe persona.<\/p>\n
<\/em>Questo significa che impiegato<\/em> eredita automaticamente da persona<\/em> tutti i suoi metodi e tutte le variabili di istanza, senza scrivere una riga di codice! Supponendo per esempio che la classe persona abbia un metodo chiamato getCodicePersonale<\/em> sar\u00e0 possibile invocarlo automaticamente anche su oggetti di tipo impiegato.<\/em>
\nVi siete mai chiesti come sia possibile invocare su qualsiasi oggetto i metodi alloc, init, dealloc<\/em> anche se in realt\u00e0 non li abbiamo scritti? Semplice, perch\u00e8 sono definiti nella classe NSObject dalla quale tutte le altre discendono, quindi vengono automaticamente ereditati. <\/p>\n
E come mai su una UILabel<\/em> posso invocare initWithFrame<\/em> anche se nella class reference di UILabel non ce n’\u00e8 traccia? anche in questo caso la colpa \u00e8 dell’ereditariet\u00e0 perch\u00e8 se guardiamo bene vediamo che la classe UILabel \u00e8 sottoclasse di UIView la quale definisce il metodo initWithFrame <\/em>che quindi \u00e8 automaticamente disponibile in tutte le sue sottoclassi.<\/p>\n
Un ulteriore flessibilit\u00e0 nell’eritariet\u00e0 \u00e8 data dalla possibilit\u00e0 di effettuare l’override<\/strong> dei metodi della superclasse. Questo che vuol dire? Vuol dire che se il metodo getCodicePersonale<\/em> della classe persona restituisce, ad esempio, il codice fiscale, nella classe impiegati<\/em> lo stesso metodo pu\u00f2 restituire il numero di matricola. Questo si ottiene semplicemente riscrivendo il metodo all’interno della sottoclasse.<\/p>\n
Il terzo pilastro della programmazione ad oggetti \u00e8 la possibilit\u00e0 di avere pi\u00f9 metodi con lo stesso nome che svolgono compiti diversi, questa che a prima vista sempre un’assurdit\u00e0 si chiama polimorfismo<\/strong>, e permette ad esempio di dichiarare due metodi con lo stesso nome ma differente tipo di parametri con questa sintassi:<\/p>\n
\r\n- (void) stampaSchedaCliente:(int)codCliente;\r\n- (void) stampaSchedaCliente:(NSStrng *)nomeCliente;\r\n<\/pre>\n
a seconda del tipo di parametro che verr\u00e0 passato al metodo sar\u00e0 invocata l’implementazione corrispondente.<\/p>\n

\n\"\"<\/a>
\n<\/center><\/p>\n","protected":false},"excerpt":{"rendered":"
Con l’articolo di oggi non intendo scrivere un trattato sulla teoria della programmazione ad oggetti, non ne…<\/p>\n","protected":false},"author":53,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[9],"tags":[46,5,18,4],"class_list":["post-1199","post","type-post","status-publish","format-standard","hentry","category-guide-teoriche","tag-developer-iphone","tag-objective-c","tag-oop","tag-programmazione"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/1199","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=1199"}],"version-history":[{"count":14,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/1199\/revisions"}],"predecessor-version":[{"id":3207,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/1199\/revisions\/3207"}],"wp:attachment":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/media?parent=1199"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/categories?post=1199"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/tags?post=1199"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}