ABONAMENTE VIDEO REDACȚIA
RO
EN
×
▼ LISTĂ EDIȚII ▼
Numărul 29
Abonament PDF

Java vs. Objective-C

Bogdan-Alexandru Vlăduț
Java Developer @ Xoomworks
PROGRAMARE

Î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:

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:

Î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:

#import 

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

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

@end

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:

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:

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:

Î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:

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.

LANSAREA NUMĂRULUI 87

Prezentări articole și
Panel: Project management

Marți, 24 Septembrie, ora 18:00
Impact Hub, București

Înregistrează-te

Facebook Meetup

Conferință

Sponsori

  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MetroSystems
  • Globant
  • Colors in projects

Bogdan-Alexandru Vlăduț a mai scris