Mostenire In POO se determina ce clase sunt superclase sau subclase examinindu-le legaturile dintre ele folosind termeneul is A este

te O/Un. Tipul obiectului unei subclase este de tipul superclasei, si relatiile dintre ele subclasa si superclasa trebuie intotdeauna sa aiba sens asa cum o masina is A autovehicul, o para is A fruct, si un portar is A angajat. Prin polimorfism putem implementa variante specifice subclaselor metodelor superclaselor. O metoda dintr-o superclasa poate adopta diferite forme dependente de subclasa careia ii apartine. Datorita polimorfismului tipul unui obiect nu poate fi determinat la compilare ci doar in faza de executie. Aceasta se numeste legare tarzie (late binding) a metodelor de instanta. Legarea tarzie permite Javei sa alega versiunea corecta a metodei apelate la executie, dependent de tipul obiectului ce este creat. Pe linga legarea tarzie exista si legarea timpurie (early binding), in care variabilele si metodele sunt cunoscute inca din faza de compilare. Mostenirea constructorilor: constructorii nu sunt neaparat mosteniti. Daca dorim sa folosim constructorul superclasei trebuie sa-l invocam prin cuvantul rezervat super, urmat de argumentele potrivite. Acest apel trebuie facut in prima linie de cod a constructorului subclasei. Obiectele se construiesc in ordinea in care au fost definite in ierarhia de clase. Daca nu apelam explicit constructorul unei superclase, Java automat va apela constructorul fara parametri al superclasei daca acesta exista, altfel va fi semnalata eroare. Prin super putem accesa si membrii clasei parinte. Nu putem, insa, accesa membrii super-superclasei (super.super). Interfata defineste protocoale de comportament fara limitari de implementare sau mostenire. Interfetele nu pot fi instantiate. Toate metodele dintr-o interfata trebuie obligatoriu implementate. Interfetele se declara prin cuvantul rezervat interface. Toate metodele din interfata sunt predefinit abstracte si publice. Interfetele pot fi declarate private sau protected doar daca sunt continute intr-o clasa. Toate variabilele dintr-o interfata trebuie sa fie initializate si sunt considerate statice si finale. Interfetele pot fi extinse. Initializarea intr-o singura linie este cel mai uzual mod de a initializa variabilele unei clase. Totusi, au dezavantajul ca initializarea nu poate arunca exceptii. O varianta ar fi initializarea in constructor. Initializarea varibilelor clasa poate fi facuta si intr-un bloc static, ceea ce conduce la salvarea memoriei. Intr-un bloc static putem arunca exceptii.
public class Exemplu{ public static int s; static{ s=7; System.out.println("salut "+s); } public static void main(String args[]) { } }

Intr-o clasa putem include oricate contexte statice. Interpretorul va apela blocurile in ordinea in care au aparut in cod. Blocurile statice se executa inaintea functiei main(). Modificatorul final permite crearea unei clase sau membru ce nu poate fi modificat. Un membru variabila final nu poate fi modificat dupa initializare. Metoda finala nu poate fi suprascrisa. O clasa finala nu poate fi extinsa. Si parametrii unei metode pot fi declarati finali, ei fiind practic constante in interiorul metodei. Aceasta nu afecteaza suprascrierea metodei.

Parametrii final nu afecteza argumentele transmise metodei singurul efect este ca ele nu pot fi modificate nici macar in interiorul metodei.
public void getNumber(final int x, final int y){ // ... }

De obicei variabilele finale sunt statice. Daca initilizarea lor nu s-a facut in momentul declararii in mod sigur ele trebuie initializate in context static. Aceste variabile sunt cunoscute ca variabile blank. Metodele finale nu pot fi suprascrise in subclase. Metodele declarate private sunt intotdeauna finale. O clasa finala nu mai poate fi clasa de baza. Toate metodele dintr-o clasa finala devin implicit finale. Declaram o clasa finala pentru: Consideratii de design Optimizarea compilarii Securitate Garbage collection si finalization In Java sistemele de rulare gestioneaza interactiunile proceselor cu memoria printr-o facilitate numita garbage collection. Garbage collection este un fir daemon (ce ruleaza in beneficiul altor fire) ce elibereaza automat memoria alocata, ce nu mai este folosita. Garbage collector ruleaza ca un fir de prioritate scazuta, asteptand dupa firele de prioritate ridicata sa elibereze procesorul. In Java 1.4 se folosesc diferiti algoritmi, printre care copying collector algorithm, care opresc toate firele aplicatiei pina cand garbage collector este incheiat. Exista si algoritmi care folosesc fire paralele pentru copying collector. In 1.5 sunt introduse mai multe modificari fata de 1.4. Garbage Collector porneste un parallel collector in locul precedentului serial collector. Daca dorim sa ne asiguram ca un obiect este colectat de garbage collector folosim codul:
myObject theObject = new myObject(); theObject = null;

Obiectul poate fi colectat cand garbage collector va rula. Garbage collectorul ruleaza sincron la intervale regulate sau asincron la intervale neregulate dependent de sistemul pe care ruleaza Java. Putem invoca garbage collectorul oricand prin invocarea metodei System.gc(). Fiecare clasa Java poate avea o metoda finalize() ce ajuta returnarea resurselor sistemului. In mod efectiv, finalizarea inseamna ca inainte ca un obiect sa fie colectat, Java Runtime System ii ofera ocazia sa se curete sigur. Java apeleza finalize() din cand in cand dupa ce sistemul determina ca un obiect este candidat pentru returnare si inainte ca obiectul sa fie colectat. Aceasta metoda poate fi utilizata pentru a elibera orice resursa non-memory utilizata de obiect, spre exemplu fisierele deschise. Orice metoda finalize() creata de utilizator trebuie sa suprascrie metoda goala finalize() din clasa Object. Semnatura este urmatoarea:

public void finalize() throws Throwable; o clasa poate avea doar o singura metoda finalize(). Suprascrierea metodei nu este permisa. Putem forta finalizarea prin apelul metodei runFinalization() din clasa System. Aceasta metoda elibereaza resursele sistem prin apelul metodei finalize() pentru toate obiectele

afectate de garbage collector. Inner si nested classes Clasele definite in interiorul altor clase se numesc clase interioare (inner) sau incuibate (nested). Acestea implementeaza relatia de agregare intre obiecte. Agregarea numita si

compunere determina faptul ca ciclul de viata al unui obiect este intr-un totul asociat obiectului gazda. Spunem ca obiectul gazda are un/o (has a) relatie cu obiectul interior. Clasele interioare (incuibate) permit claselor exterioare sa le foloseasca fara a modifica ierarhia de mostenire. Clasele interioare (incuibate) se declara la fel ca clasele obisnuite doar ca definirea lor se face intre acoladele clasei exterioare. Clasele interioare (incuibate) pot mosteni orice superclasa sau implementa orice interfata. Clasele incuibate sunt clase statice, in timp ce clasele interioare sunt non-statice. Clasele interioare nu pot avea membri statici sau initializatori statici.
public class Exterioara { private int i = 100; Interioara in; public Exterioara(int i) { this.i = i; in = new Interioara(++i); } class Interioara { int y; public Interioara(int startVal) { System.out.println(i); y = startVal; } } }

Trebuie sa avem o instanta a clasei exterioare inainte ca sa putem instantia clasa interioara. De obicei instantierea clasei interioare se face in constructorul clasei exterioare. Dupa ce am creat un obiect interior el refera implicit instanta clasei exterioare, de care apartine. Toti membrii clasei exterioare sunt direct si automat accesibili clasei interioare, inclusiv cei privati. Cand instantiem o clasa interioara dintr-o clasa externa trebuie mai intai instantiata clasa exterioara corespunzatoare. Aceasta se poate face intr-o singura linie:
Exterioara.Interioara in = new Exterioara().new Interioara();

Sau in doua linii:

Exterioara out = new Exterioara(); Exterioara.Interioara in = out.new Interioara(); in.metoda();

Apelul unui membru din clasa interioara se face: Calificarea completa a tipului clasei interioare este Exterioara.Interioara. Aceasta calificare completa se foloseste doar din exteriorul clasei esterioare. Din interior tipul este Interioara. Dupa compilare se va crea un fisier cu numele: Exterioara$Interioara.class. Obiectele statice incuibate opereaza in strinsa asociere cu clasele exterioare, dar nu sunt legate de nicio instanta a acestora. La fel ca metodele si variabilele statice, clasele incuibate pot fi folosite fara o instanta a clasei exterioare. Asadar, clasele incuibate pot fi create fara a crea o instanta a clasei exterioare. In afara clasei exterioare crearea clasei incuibate se face astfel:
Exterioara.Interioara obj=new Exterioara.Interioara();

Putem crea oricate instante a unei clase incuibate. Aceasta caracteristica a claselor incuibate le deosebeste de variabilele statice prin aceea ca o clasa are o singura copie a fiecarei variabile statice. Urmatorul cod are eroare de compilare:
public class Exterioara {

static int j; int k; static class Interioara { void aMethod() { int l = j; int m = k; } }

A doua atribuire este ilegala pentru ca intr-un context static folosim o variabila nestatica, k. O clasa locala interioara este o clasa definita in interiorul unei metode.
public class Exterioara { public void aMethod(final int i) { class Interioara { private int y; public Interioara(int startVal) { System.out.println(i); y = startVal; } } Interioara in = new Interioara(20); System.out.println(in.y); } public static void main(String[] args){ new Exterioara().aMethod(10); } }

Trebuie sa declaram variabilele locale si parametrii metodei in care facem definitia drept final daca dorim sa ii accesam din clasa locala interioara. Valorile variabilelor si parametrilor finali vor fi copiate fiecarei instante a clasei locale. Unul dintre motivele pentru care declaram o clasa interiora ca locala este acela ca devine complet ascunsa codului exterior. Pentru clasele locale nu se declara modificatori de acces expliciti. Domeniul clasei locale este limitat la blocul in care a fost declarata. O clasa interioara anonima este o clasa interioara ce este declarata la apelul unei metode si nu are nume. Instantele claselor anonime sunt intotdeauna create si utilizate in acelasi loc in care clasa a fost definita, asa incat nu avem nevoie sa folosim numele clasei pentru a declara o referinta sau a crea o instanta. Clasele anonime nu au constructor. O clasa anonima poate fi subclasa sau poate implementa o interfata, dar nu poate fi o subclasa ce implementeaza interfete. Modalitatea tipica de utilizare a claselor anonime este la manipularea evenimentelor, ele sunt folosite pe post de receptori. Sintaxa generala este :
metoda( new Clasa(){ //corp clasa }); Clasa este de fapt o superclasa.

In cod Clasa anonima extinde de fapt Clasa. Clasa anonima a fost instantiata (o data si numai o data) in momentul declararii si apelului metodei metoda(), prin cuvantul rezervat new. Programare generica Programarea generica a fost introdusa in J2SE 5.0 si modifica semnificativ sintaxa limbajului facand codul mult mai sigur din punct de vedere al tipului de date (type safe).

Programarea generica foloseste parametri cu tip atunci cand defineste clase sau metode. Codul generic este inrudit cu tipurile parametrizate sau template-urile. Programarea generica inlatura necesitatea conversiei de tip cu avantaje substantiale pentru programatori si pentru procesul de debugging. Codul non-generic este denumit cod legacy.
// Legacy Code List list = new ArrayList();

//Generic Code List<Integer> list = new ArrayList<Integer>();

In exemplul anterior ambele linii creaza o lista de obiecte. Prima creza un sir ce accepta orice tip de obiect. Aceasta inseamna ca anumite metode ale clasei ArrayList necesita conversie manuala ceea ce poate conduce la aparitia erorilor la executie. In cea de-a doua linie am folosit cod generic. Tipul elementelor sirului a fost scris intre semnele < > si determina ca toate elememtele sunt de tip Integer. Avantajele folosirii tipului generic sunt: Colectiile generice stocheaza numai tipuri cunoscute Erorile de tip sunt prinse inca in faza de compilare In mojoritatea cazurilor elimina nevoia de conversie Codul este mai usor de inteles Timpul de executie este scurtat Este usor de trecut de la legacy la generic pentru ca exista backward compatibilty intre generic si legacy Dezvantaje: Codul generic e greu de dezvoltat Codul generic e greu de interpretat Urmatorul exemplu ilustreaza producerea unei erori la executie din cauza folosirii defectoase a tipului row. Elementele listei se considera de tip Object. Eroare nu a fost identificata la compilare. In versiuni mai mari de 5, avem atentionari in ceea ce priveste folosirea tipului row.
import java.util.*; public class GenericError { public static void main(String[] args) { // This list is not type safe, as it can store any type of object List list = new ArrayList(); list.add(5); list.add("4"); for (Iterator i = list.iterator(); i.hasNext();) { // urmatoarea linie va genera o eroare la rulare relativ la conversia string-ului "4" in Integer int value = ((Integer) i.next()) * 10; System.out.println(value); } } }

Solutia este:

import java.util.*; public class GenericFix { public static void main(String[] args) { // lista va fi declarata de tip Integer List<Integer> list = new ArrayList<Integer>();

list.add(5); list.add("4"); for (Iterator<Integer> i = list.iterator(); i.hasNext();) { int value = (i.next()) * 10; System.out.println(value); } } }

In care primim eroarea de incompatibilitatea a tipurilor inca din faza de compilare. Compilatorul foloseste un proces numit erasure sau type erasure pentru a asigura faptul ca codul generic este compatibil cu codul legacy, de aceea cele doua tipuri de cod pot fi folosite simultan.
class ABC<T>{ // declares an object of type T T obj; // the constructor ABC (T aObj) { obj = aObj } // returns obj T getObj(){ return obj; }

In aceasta clasa generica procesul de compilare este urmatorul: tipul parametrizat generic, T, este indepartat si inlocuit de tipul corespunzator prin eventuale conversii. Daca nu se specifica niciun tip atunci se foloseste tipul Object pentru a asigura compatibilitatea cu alte clase. Definirea unui tip generic se face dupa urmatoarea sintaxa:
class nume<lista_parametri_generici>{ }

Sintaxa poate fi aplicata interfetelor sau oricaror tipuri container din ierarhia Collection precum: List, Map, etc. Poate fi aplicata, de asemenea, constructorilor sau metodelor unei clase. Parametrii sunt intotdeauna tipuri clasa.
public interface<T>{ void add(T e); } List<Account> list = new ArrayList<Account>(); Map<Integer, String> level = new HashMap<Integer, String>();

Putem defini metode generice in interiorul claselor generice si putem defini clase generice ce extind clase generice sau nongenerice. Urmatorul cod va genera eroare la atribuire din cauza incompatibilitatii tipurilor.
class Gen<Type> { // The methods for generic class behavior; }

class GenTest { public static void main(String[] args) { // initializarea instantelor claselor generice Gen Gen<Integer> A = new Gen<Integer>(); Gen<String> B = new Gen<String>(); A = B; //eroare! } }

Putem folosi colectii generice. Acestea pot fi declarate cat si intializate ca generice. Daca o colectie este initializata ca generica, dar nu are o declaratie generica atunci ea va accepta obiecte arbitrare. Aceasta este ilustrat in exemplul urmator:
List list =new ArrayList<Integer>(); list.add(5); list.add("4");

Apeluri ca: sunt posibile dar vor genera atentionari la compilare. La executie, insa, urmatoarea sintaxa va genera eroare:
for (Iterator<Integer> i = list.iterator(); i.hasNext();) { int value = (i.next()) * 10; System.out.println(value); } O restricie fundamentala in cazul programarii generice este ca un tip generic T nu este compatibil cu Object. Astfel, nu putem face atribuirea List<T> la un List<Object>.

Motivatia vine din faptul ca un obiect de orice tip ar putea fi inserat in lista.
public class Generic { public static void main(String[] args) { List<Account> list = new ArrayList<Account>(); //desi Account extinde Object, o lista Account nu poate // fi atribuita unei liste Object. List<Object> objects = list;

} }

Tipul identic cu codul legacy List. In anumite situatii trebuie sa facem conversii explicite cand utilizam tipuri generice. Cazul cel mai frecvent este atunci cand folosim obiecte instante ale unor clase derivate din clasa declarata ca parametru. Un exemplu este in cele ce urmeaza:
public class Generic { public static void main(String[] args) { List<Account> list = new ArrayList<Account>(); // Adaugarea unui element dintr-o clasa derivata din Account list.add(new Mortgage()); // cand extragem elementul trebuie sa facem un cast Mortgage mortgage = (Mortgage) list.get(0); } } class Account { } class Mortgage extends Account { }

class Account { } List<Object> este practic

Putem adauga si liste intregi intre elementele unei liste existente, caz ilustrat mai jos:
import java.util.*; public class Generic{ public static void main(String[] args) { List<Mortgage> mortgageList = new ArrayList<Mortgage>(); mortgageList.add(new Mortgage()); List<Deposit> depositList = new ArrayList<Deposit>(); depositList.add(new Deposit()); List<Account> accountList = new ArrayList<Account>(); accountList.addAll(mortgageList); accountList.addAll(depositList); } }

class Account { } class Mortgage extends Account { } class Deposit extends Account { }

Daca adaugarea a fost posibila, si in cazul extragerii vom avea nevoie de cast, atribuirea directa nu este posibila, asa precum am aratat anterior. Urmatorul cod genereaza eroare la compilare: accountList=mortgageList; Solutia pentru atribuirea subtipului unui supertip este folosirea sintaxei: <? extends Account>. ? poarta denumirea de wildcard. Codul din exemplul anterior se modifica, pentru atribuire, dupa cum urmeaza:
import java.util.*; public class Generic { public static void main(String[] args) { List<Mortgage> mortgageList = new ArrayList<Mortgage>(); mortgageList.add(new Mortgage()); List<? extends Account> list = mortgageList; list = mortgageList; } } class Account { } class Mortgage extends Account { }