Java vs. Objective-C

Bogdan-Alexandru Vlăduț
Java Developer @ Xoomworks

În rândurile acestui articol îmi propun să realizez o scurtă introducere în mediul de dezvoltare iOS, urmărind în special caracteristicile limbajului de programare Objective-C. Voi viza elementele definitorii ale limbajului, precum și detalii privind cel mai utilizat framework în acest context, Cocoa-Touch. Concluziile exprimate în acest articol sunt din punctul de vedere al unui programator Java. Veți putea identifica multe comparații cu acest limbaj de programare.

Nu îmi propun ca acest articol să fie un tutorial detaliat de Objective-C, ci o expunere critică a unor caracteristici ale acestui limbaj de programare. Pentru detalii puteți utiliza documentația oficială Apple, disponibilă la adresa https://developer.apple.com/, precum și alte tutoriale disponibile pe Internet. Câteva dintre punctele atinse pe parcursul articolului vizează modalitatea de implementare a principiilor OOP în Objective-C, expresiile lambda și o paralelă a gestionării memoriei în Java și Objective-C.

Probabil primul lucru la care ne duce cu gândul Objective-C este sintaxa "ciudată" a acestui limbaj de programare. Exemplul de cod de mai jos surprinde declararea unei metode, instanțierea unui obiect și apelul metodei anterior definite:

     -(void) setNumerator:(int) numerator andDenominator:                                         (int) denominator{
                self.numerator = numerator;
                self.denominator = denominator;
      }
      ...

      MSGFraction *fraction = [[MSGFraction alloc] init];
      [fraction setNumerator: 3 andDenominator: 7];

Acum, după ce am făcut cunoștință cu Objective-C, putem vorbi despre tipurile de date ale acestui limbaj de programare. Objective-C este o extensie a limbajului C, fiind astfel moștenite toate tipurile de date existente în C: arrays, _pointer_i, structuri etc. .Poate singura diferență importantă în ceea ce privește tipurile de date numerice din Objective-C față de Java sunt tipurile unsigned, păstrate în cazul primului limbaj menționat. Spre deosebire de Java, unde există câte o clasă wrapper pentru fiecare tip numeric primitiv, aici gestionarea se realizează prin intermediul unei singure clase, NSNumber. Această clasă cuprinde metode utile de instanțiere specifice pentru fiecare tip de date. De exemplu, pentru instanțierea unui obiect ce reprezintă un întreg unsigned, poate fi utilizată una dintre următoarele construcții:

NSNumber *num = [[NSNumber alloc] initWithUnsignedInt: 7];

sau

NSNumber *num = [NSNumber numberWithUnsignedInt: 7];

Acest tip de instanțiere implementează practic Design-Pattern-ul Abstract Factory. Clasa abstractă NSNumber returnează, în funcție de metoda de instanțiere apelată, o instanță a uneia dintre următoarele clase:

• NSCFNumber - pentru toate tipurile numerice și pentru tipul caracter;
• NSBooleanNumber - pentru tipul primitiv boolean.

Ulterior, în cod, apelând metode precum intValue, booleanValue etc., vor fi create obiecte concrete (sunt, de fapt, tipuri primitive): fie prin returnarea valorii cu care a fost instanțiat factory-ul - dacă este stocat același tip cu cel cerut de apelul metodei, fie convertind valoarea la tipul solicitat. Deși Objective-C nu implementează auto-(un)boxing, putem identifica două avantaje ale acestei abordări:

• subclasele NSNumber cuprind metode utile de conversie între tipurile de date (metode asemănătoare sunt implementate și de clasele wrapper din Java);
• în acest fel vor fi utilizate preponderent tipurile de date primitive , fiind instanțiat un obiect wrapper doar în situațiile necesare. De exemplu, pentru stocarea datelor într-o listă. În Java, deși conversia de la tipuri primitive la obiecte wrapper este facilă, folosirea celei de-a doua opțiuni poate introduce probleme de performanță semnificative.

În ceea ce privește aplicarea principiilor OOP în Objective-C, prima diferență față de Java poate fi identificată în cazul definirii unei clase. Dacă în Java o clasă este definită într-un singur fișier, având extensia .java, în Objective-C o clasă constă din două componente:

• componenta publică, denumită interfață, cuprinde metodele publice ale clasei. Trebuie menționat faptul că interfața din Objective-C nu este echivalentă cu cea din Java. Aici trebuie definite atât metodele instanței, cât și metodele clasei (metodele statice din Java). O posibilitate pe care eu o consider utilă este aceea a declarării câmpurilor în interfață. Dacă aceste variabile sunt marcate cu identificatorul @property atunci vor fi generate automat metode getter și setter, în funcție de parametrii specificați. În Java, o astfel de abordare este posibilă cu ajutorul framework-ului Lombok, însă acesta necesită un compilator special;

#import 

@interface MSGFraction : NSObject
@property (nonatomic) int numerator;
@property (nonatomic) int denominator;

-(void) setNumerator:(int) numerator andDenominator:(int) denominator;

@end

• componenta privată a unei clase cuprinde implementarea propriu-zisă a metodelor declarate în interfață.

Echivalentul unei interfețe din Java este denumit în Objective-C protocol și se definește cu ajutorul identificatorului @protocol. Un lucru merită însă amintit în cazul protocoalelor din Objective-C: se realizează distincția între metodele ce vor trebui implementate în mod obligatoriu într-o clasă ce se conformează unui protocol și metodele opționale (definite prin intermediul identificatorilor @required, respectiv @optional). O utilitate majoră a acestei posibilități oferite de Objective-C se regăsește în cadrul _Design Pattern-_ului Delegate, acesta fiind un pattern de bază în dezvoltarea iOS. Cel mai adesea, pentru a oferi posibilitatea ca o clasă să nu implementeze o anumită metodă, în Java este folosit un adapter, adică o clasă ce oferă o implementare standard pentru toate metodele dintr-o interfață. În exemplul de mai jos a fost definit un adapter pentru MouseListener. Ulterior, în proiect, va fi utilizată această nouă clasă și vor fi suprascrise doar metodele de care este nevoie, cel mai adesea, doar mouseClicked.

public class MouseListenerAdapter implements MouseListener{

        public void mouseClicked(MouseEvent e){}
        public void mouseEntered(MouseEvent e){}
        public void mouseExited(MouseEvent e){}
        public void mousePressed(MouseEvent e){}
        public void mouseReleased(MouseEvent e){}
    }

Dacă în Java de-abia în ultima versiune au fost introduse expresiile lambda, corespondentul din Objective-C, denumit bloc, poate fi utilizat începând cu versiunea 4 a iOS. Un bloc este o structură de cod manipulată asemeni unei funcții C, ce este folosită cel mai adesea pentru apeluri de tip callback. Un bloc reprezintă de fapt un pointer la o funcție C. Blocurile cuprind cod nativ C, fiind gestionate de un compilator extins pentru a recunoaște astfel de structuri, iar Apple chiar militează pentru acceptarea în specificația standard de C a blocurilor.

    int multiplier = 7;
    int (^myBlock)(int) = ^(int num){ return num*multiplier; };
    ...
    myBlock(5);

Asemeni unei funcții, un bloc poate primi parametri. În plus , are acces la variabilele anterior definite în cod, dar nu le poate modifica. Acesta realizează practic un snapshot cu valorile din momentul declarării și dacă după declararea blocului acea variabilă a fost modificată, va fi înregistrată totuși valoarea din momentul declarării. Dacă la definirea unei variabile se utilizează identificatorul block , atunci acea variabilă poate fi și modificată în interiorul unui bloc. Sunt apelate exact ca o funcție C și pot fi asignate unei variabile - pot fi apelate metode specifice ale obiectelor precum: copy, retain, etc. .

Dintre avantajele utilizării blocurilor menționăm:

• sunt definite acolo unde este nevoie de ele, chiar și în interiorul unei metode (nu mai este nevoie să fie definită o nouă metodă) - oferă o mai bună consistență și lizibilitate a codului;
• au acces la variabilele de context - definite anterior. Astfel nu este nevoie ca aceste variabile să fie trimise ca parametri pentru o metodă;
• sunt optimizate pentru execuția în paralel;
• execuția unui bloc e mult mai rapidă decât cea a unei metode (nu este nevoie de lookup).

Cum aceste structuri de cod sunt foarte des utilizate în framework-ul Cocoa Touch, au fost incluse și în cadrul unui Design Pattern: Completion Handler. În acest context blocurile sunt utilizate asemeni unei funcții callback: la terminarea unei acțiuni va fi apelat un bloc.

Voi realiza în cele ce urmează o analiză a claselor specifice colecțiilor de date din Objective-C și Java. În Objective-C, fiecare clasă destinată stocării datelor are două variante:

• immutable - conținutul unui obiect este stabilit la instanțiere și nu poate fi modificat apoi;
• mutable - extinde tipul immutable și conține metode pentru modificare/adăugare/ștergere;

Cu ajutorul unor metode utile obținerea unui obiect mutable dintr-unul immutable (sau invers) se realizează foarte ușor:

    NSArray *immutableArray = @{"A", "B", "C"};
    NSMutableArray *mutableArray = [[NSMutableArray alloc] init];
    [mutableArray addObjectsFromArray: immutableArray];

Folosirea unor obiecte immutable are o utilitate foarte importantă în programare, printre avantajele acestei abordări numărându-se:

• stocare eficientă în memorie, întrucât nu va fi alocat mai mult spațiu decât este necesar;
• la trimiterea unui obiect ca parametru pentru o metodă putem fi siguri că acesta nu va fi modificat;
• cea mai eficientă metodă de implementare a unui mecanism thread-safe este folosind obiecte immutable.

În Java nu există astfel de colecții. Singura posibilitate este utilizarea java.util.Collections pentru a crea un wrapper al unei colecții trimise ca parametru. Colecția returnată va arunca o excepție în cazul în care se apelează o metodă de modificare a listei (de exemplu, add()). Dar, dacă este modificată colecția inițială, aceste modificări vor fi resimțite și în cea wrapper, întrucât reține doar o referință la cealaltă. În acest moment ar fi foarte dificilă adăugarea unei astfel de posibilități în Java: ar implica modificarea întreguluiframework de colecții sau crearea unuia nou.

O problemă importantă în cazul oricărui limbaj de programare o reprezintă posibilitățile pe care acesta le pune la dispoziție pentru gestionarea memoriei. Chiar dacă pentru a lucra în iOS nu mai este necesară înțelegerea tuturor conceptelor prezentate în această parte, o analiză mai profundă ne va ajuta să înțelegem mecanismele utilizate pentru gestionarea memoriei în iOS. Fiecare obiect din Objective-C conține un câmp (denumit 'reference count') ce păstrează numărul de referințe active către acesta. Apelul metodei 'retain' determină incrementarea acestui număr și returnarea unei referințe la obiect. Când nu mai este nevoie de un obiect se apelează 'release', ceea ce determină decrementarea reference count. Atunci când counter-ul a ajuns la zero, se apelează imediat metoda dealloc, echivalentă a metodei finalize() din Java, cu deosebirea că dealloc va fi cu siguranță apelată și putem determina chiar și momentul. Cu alte cuvinte, vom ști încă din timpul compilării cât timp va exista un obiect.

Începând cu iOS 5 a fost introdus un sistem de management al memoriei denumit Automatic Reference Counting (ARC). Logica utilizată este identică cu cea anterior prezentată, cu deosebirea că nu mai intră în atribuțiile programatorului. Compilatorul este echipat cu un analizor al codului sursă pentru a determina unde începe folosirea unui obiect, precum și când acest obiect nu mai este utilizat. Altfel spus, apelul metodelor retain și release va fi realizat automat.

Putem vedea astfel cum o constrângere a mediului (resursele limitate ale mediului mobil) poate conduce la găsirea unei soluții mai eficiente. Inițial, pentru OS era utilizat un Garbage Collector (GC). Începând cu OS X 10.8 (Mountain Lion) această abordare este deprecated, optându-se și în acest caz pentru utilizarea ARC.

Principalul avantaj al ARC este dat de identificarea rapidă și eficientă, încă de la compilare, a garbage-ului. În acest fel nu este nevoie ca un proces adițional, consumator de resurse, să ruleze constant pentru identificarea resurselor ce pot fi reutilizate. Există și câteva dezavantaje importante ale ARC, care nu cred însă, că pot înclina balanța în favoarea GC:

• pentru fiecare obiect va fi stocat un câmp suplimentar, crescând astfel spațiul de memorie cu cel puțin un byte per obiect;
• asignarea și eliminarea referinței unui obiect aduc o problemă de performanță datorită nevoii de a realiza o operație suplimentară;
• cea mai importantă problemă este detectarea retain cycle (atunci când două obiecte se referențiază reciproc, dar nu sunt referențiate și din altă parte a codului). Pentru a rezolva această problemă au fost introduse două tipuri de referințe: strong și weak. O referință strong determină incrementarea _counter-_ului intern, pe când una weak, nu. Dacă nu există nicio referință strong la un obiect, acesta este considerat garbage. În Java nu există această problemă. GC determină practic referințele active, cele la care se poate ajunge pornind de la rădăcina _heap-_ului. Toate celelalte obiecte vor fi eliminate din heap.

Am văzut așadar că în Objective-C clasa wrapper a tipurilor primitive implementează Design Pattern-ul Abstract Factory și că lipsa auto-(un)boxing nu trebuie neapărat privită ca un impediment. Am putut observa, de asemenea, faptul că framework-ul de colecții din Objective-C este mai rafinat decât cel din Java. Pe de altă parte, în Objective-C nu există tipuri generice (deși, ar argumenta unii, implementarea din Java este la rândul ei una problematică). În final, am realizat o comparație a modalităților de gestionare a memoriei în cele două limbaje de programare, concluzionând că la acest capitol, Objective-C propune o metodă mai simplă și mai eficientă decât GC.

Pentru obiecții, nelămuriri sau încurajări aștept să îmi scrieți.