TP

TP Curs 1

Problema - descompunere / constructie
Domeniul problemei contine procese / date, domeniul solutiei contine un model (cu algoritmi si programe)
Procesul de trecere de la domeniul problemei la domeniul solutiei se cheama procesul de abstractie
Compararea rezultatelor observabile din domeniul problemei cu cele obtine in domeniul solutiei imbunatatesc procesul de abstractie.

proces de dezvoltare software, numit si ciclu de viata, contine
input : cerintele de sistem
output : un produs realizat
Tehnologii de asistență software asistate de calculator (CASE).Ele sunt instrumente care oferă asistență automată pentru dezvoltarea de software. Scopul introducerii instrumentelor CASE este reducerea timpului și a costurilor de dezvoltare software și îmbunătățirea calității sistemelor dezvoltate. Interesul pentru instrumentele și mediile CASE se bazează pe așteptările privind creșterea productivității, îmbunătățirea calității produselor, facilitarea întreținerii și a face sarcina inginerilor de software să fie mai puțin odioasă și mai plăcută.

constructia software (un proces cu 3 faze)
1) design detaliat
2) cod, unitati de testare
3) compoziția soluției

1)
design nivel 1  : proiectarea sistemului general (un black box mare)
design nivel 2,3,4 (detaliat)
nivel 2 -> design la nivel de subsystem / pachet
nivel 3 -> design la nivel de clasa
nivel 4 -> design la nivel de date si de functii

2) cod si testare pentru unitate, planificarea integrarii si testarea la nivel de subsistem
integrarea sistemului și planificarea testării

DESIGN

obiectiv : obtinerea unui (sub)system bun
reutilizarea resurselor existente
metode iterative try-error si divide et impera
complexitate : abordari top-down sau bottom-up
programatorii priceputi : folosesc euristice

caracteristici de proiectare dezirabile (de dorit) (caracteristici de design intern și extern)
--------------------------------------------------------------------------------------------------------------
caracteristici de design extern:

availability -> disponibilitate
reliability -> fiabilitate
performance -> performanta
fault tolerant -> toleranta la erori
maintainability -> mentenabilitate (proprietate a unui produs de a fi întreținut și reparat cu ușurință)
robustness -> robustete (rezistent la munca)
security -> securitate
interoperability -> interoperabilitate (abiliatea proceselor de a lucra împreună pentru realizarea unui scop comun)
portability -> portabilitate
usability -> uzabilitate
functionality -> functionalitate
system integrity -> integrarea sistemului
consistency -> consistenta
efficiency -> eficienta
--------------------------------------------------------------------------------------------------------------
caracteristici de design intern:

complexitate minima : cuplaj liber între piesele de proiectare si coeziune ridicată
coeziune = legatura interna stransa

metrice pentru masurarea complexitatii :
(fan-in, fan-out)
fan-in (numarul maxim de intrari care se pot accepta)
fan-out (numarul maxim de intrari care pot fi conectate la iesire, care pot fi apelate)

extensibilitate / scalabilitate
reutilizabilitate
stratificare
tehnici standard
ușurință de întreținere
--------------------------------------------------------------------------------------------------------------
modele de calitate
McCall (1977), Boehm (1978), ISO 9126 (1990), Dromey (1996)

o euristica este orice abordare a rezolvării problemelor sau a descoperirii de sine care utilizează o metodă practică care nu este garantată a fi optimă, perfectă sau rațională, dar care este totuși suficientă pentru atingerea unui obiectiv imediat, pe termen scurt.

euristici principale : vezi curs

paradigme de programare :

obiectiv : prezentarea principalelor modele de calcul și paradigma de programare
alegerea limbajului de programare potrivit
- problema dificila
- probmela -> programarea maparii limbajului

1) programare secventiala

executa o declaratie la un moment dat (folosit pe un single-processor)
transforma datele de intrare in rezultate conform algoritmului implementat.
de obicei determinist

determinism -> fenomenele sunt generate de înlănțuiri de cauze și efecte, prin condiționări și legități, prin interacțiuni necesare și repetitive.

2) programare concurenta

entitatile de programare se executa simultan (in paralel)
schimb de informații dinamic
o mare varietate de modele concurente
suport de executie
transforma secvențial în programare simultană (efort de cercetare pentru automatizarea acestei lucrări)
strategie de descompunere a sarcinilor mari în mai multe sarcini mai mici care se execută concomitent.
alocarea sarcinilor mai mici mai multor lucrători pentru a lucra simultan.

--------------------------------------------------------
clase de algoritmi și probleme, paralele și distribuite
--------------------------------------------------------
1) programare paralela

formă specială de programare concurentă (multiple procesoare fizice), (partajarea memoriei)

abordări pentru construirea aplicațiilor paralele :
paralelismul funcțional
paralelism master-slave
paralelism spmd (same code replicated)

principalele sarcini de programare paralelă :
descompunerea, distribuirea si coordonarea task-urilor / sarcinilor

2) programare distribuita

formă specială de programare concurentă (multiple procesoare fizice) (situata de la distanță) (fara partajare a memoriei)
comunicarea intre procese (canale de comunicatie) (schimbul de mesaje)

--------------------------------------------------------------
clase de algoritmi și probleme, transformaționale și reactive
--------------------------------------------------------------
1) programare transformațională

bazata pe secventa : citeste date, proceseaza date, furnizeaza rezultate
pot fi văzute ca funcții ale n intrări care generează m ieșiri
comportamentul programului depinde de starea curentă a programului și de intrare
poate fi paralelizat

2) programare reactiva

interacționează cu mediul în timpul executării
nu poate fi specificata ca o funcție
programare condusă de evenimente
inerent nedeterminist

-------------------
modele de calcul
-------------------
programare orientată procedural, imperativ -> proceduri, algoritmi, principiul substitutiei (Pascal, C, C++)
programare orientata pe obiect -> obiecte si clase (Simula, SmallTalk, C++, Java, C#)
programare functionala -> functii, calcul cu lambda (Lisp, ML, Haskel)
programare logica -> foloseste calculul predicatului (Prolog, SQL)
programare orientata pe constrangeri -> relații invariante

programare functionala (caracteristici principale)

funcții de ordin superior - functii care iau alte functii ca argumente sau tip returnat
date imuabile - în loc să modifice valorile existente, limbajele funcționale operează adesea pe o copie a valorilor originale pentru a le păstra
concurenta - este mai simplu de implementat, datorata datelor imuabile
transparență referențială - calculele pot fi efectuate în orice moment, producând întotdeauna același rezultat (similar cu metodele statice din Java)
evaluare leneșă - valorile pot fi calculate numai atunci când este necesar, deoarece funcția poate fi evaluată oricând, oferind mereu același rezultat

programarea reactiva
concepte principale: fluxuri de date și propagarea modificărilor de date
pentry x = y + z; daca se schimba valorile lui y si z atunci valoarea lui x se  va modifica si ea.
codul gestionează valorile în timp ce acestea variază în timp, propagând modificări la fiecare parte a codului care folosește aceste valori
poate fi implementate in multe limbaje de programare : Java, JavaScript, C#, SCala, C++, Python, etc.
combină modelul de observare, modelul de iterator și programarea funcțională
utilizează observeri pentru a reprezenta fluxuri de date asincrone
abstractizeaza toate detaliile threading-ului, concurentei si a sincronizarii.
permite scrierea ușoară a programelor concurente

TP Curs 2

diagrama use case -> surprinde cerințele și ilustrează interacțiunile utilizatorilor cu sistemul
diagrama de clase si de obiecte -> ilustreaza structura logica a sistemului
diagrama de secvență, colaborare si de stare -> ilustreaza comportamentul sistemului
diagrama de activitate -> ilustrează fluxul evenimentelor într-un caz de utilizare
diagrama de pachete -> arată pachete de clase și dependențele lor
diagrama de componente -> ilustrează structura fizică a software-ului
diagrama de implementare -> arată maparea software-ului la configurațiile hardware

diagrame de clase si de obiecte


descriu clasele și obiectele din sistem și relațiile dintre ele
relatii (asociere, agregare/compozitie, generalizare (mostenire), realizare, dependenta)
o clasa poate arata (atribute, operatii, constrangeri)
(+) -> camp public, (-) -> camp privat, (#) -> camp protected, (+) -> metoda publica, (-) -> metoda privata

asocieri

folosirea asocierilor (trei scopuri generale) reprezinta :
1) o situatie in care un obiect de o clasa foloseste serviciile unui alt obiect, sau ele isi folosesc reciproc serviciile - adica un obiect ii trimite mesaje celuilalt sau isi trimit mesaje intre ele. (in primul caz, navigabilitatea poate fi unidirectionala, il cel de-al doilea trebuie sa fie bidirectionala)
2) agregarea sau compozitia - unde obiecte de o clasa sunt intregi compusi din obiecte de cealalta clasa ca parti.
3) o situatie in care obiectele sunt inrudite, chiar daca nu schimba mesaje. Aceasta se intampla de obicei cand cel putin unul dintre obiecte este folosit in esenta la stocare de informatie.

asociere bidirectionala daca avem clasele

public class ResearchProj
{
	private Professor theProfessor;
	public ResearchProj() { ... };
}

public class Professor
{
	private ResearchProj[] rp = new ReasearchProj[MAX_RP];
	public Professor() { ... };
}

unidirectionala ar fi fost daca nu declaram variabial theProfessor in clasa ResearchProj

Agregare = mecanismul prin care definim oclasă nouă ce include una sau mai multe date membre care au ca tip clase deja definite.
Ne permite construirea de clase complexe pornind de la clase mai simple
relatie de tip "are o\un"
o forma speciala de asociere care modeleaza relatia parte-intreg intre un agregat (intregul) si partile sale
intregul e cel la care se marcheaza rombul
proprietati agregare : tranzitivitate, nereflexivitate

Realizare -> o interfata serveste post de contract pe care o clasa este de acord sa-l indeplineasca

Dependenta -> relatie de tip "foloseste". O relaţie între două elemente ale modelului în care o
schimbare în unul dintre elemente poate cauza o schimbare în celălalt (de ex Client -> Furnizor)
(StudentReportGenerator -> Student)

forward engineering -> de la uml trecem la implementarea metodelor


diagrame de interacțiune

descriu modul în care grupurile de obiecte colaborează
surprinde de obicei comportamentul unui singur caz de utilizare
arată obiectele implicate și mesajele transmise printre obiecte
arată colaborarea dintre obiectele unui caz de utilizare

diagrame  de secventa

arată obiectele implicate în interacțiune
linie verticala punctata sub obiecte
fiecare mesaj mută fluxul de control de la un obiect la altul
un use-case poate avea mai multe scenarii (de ex cand cumperi un produs de la vending machine si nu ai de primit rest, ar fi un best-case scenario)

diagrame de activitate

stare de îndeplinire a unor sarcini
diagramele de activitate descriu secvențe de activități
suport pentru un comportament condiționat și paralel

branch - ramura

un punct de decizie la care există două sau mai multe căi de flux de control posibile
branch-ul este exclusiv mutual

merge - combinare

multiplica tranzitia de intrare, are un iesire unica

fork

când tranziția de intrare este declanșată, tranzițiile de ieșire sunt luate în paralel
poate specifica programarea concomitentă

diagrame de pachet

ajuta la descompunerea sistemelor mari în subsisteme
un pachet este o colecție de elemente de modelare care sunt grupate togheter deoarece acestea sunt legate în mod logic
la definirea pachetelor, ar trebui aplicate principiile coeziunii și cuplării

diagrama de componente

o diagramă a componentelor arată modul în care componentele sistemului se raportează între ele
diferenta intre diagrama de componente si cea de pachete :
diagrama de pachete : grupare logică a elementelor de proiectare.
diagrama de componente : componente fizice


diagramele de componente pot fi combinate cu diagrame de desfășurare pentru a arăta locația fizică a componentelor sistemului

deployment diagrams - diagrame de implementare

arată arhitectura fizică a sistemului
arată configurația elementelor de procesare în timp de rulare și a componentelor și proceselor software localizate pe acestea
configurația arată nodurile și asociațiile de comunicare
nodurile sunt utilizate de obicei pentru a afișa calculatoare, în timp ce asociațiile de comunicare arată rețeaua și protocoalele utilizate pentru a comunica între noduri
diagramele de implementare pot afișa fie tipuri de mașini, fie numele lor și componentele active dintre noduri

mostenirea si polimorfismul

o subclasa extinde caracteristicile superclasei sale
fiecare instanta a subclasei este o instanță a superclasei și nu invers

substituibilitatea subtipurilor

o valoare a unui subtip poate apărea oriunde este de așteptat un supertip
un obiect subclasa poate apărea oriunde este de așteptat un obiect supercalzant
o instanță a unei subclase poate întotdeauna înlocui o instanță a superclasei sale

widening
conversia unui subtip la unul dintre supertipurile sale

downcasting

conversia unui supertip la unul dintre subtipurile sale
are nevoie de un cast explicit (nu este sigur intotdeauna, paote genera exceptii)

polimorfismul are 2 tipuri principale
1) universul
polimorfismul universal are 2 subtipuri
a) parametric -> o funcție funcționează uniform într-o serie de tipuri care prezintă o structură comună (generic)
b) includere -> o funcție funcționează uniform pe o serie de tipuri guvernate de relația subtipului
2) ad-hoc
polimorfismul ad-hoc are 2 subtipuri
a) overloading (supraincarcarea) -> folosind o funcție cu același nume, dar parametri diferiți și cod diferit, decizia de a selecta o funcție depinde de parametrii de apel
b) coercion (constrangere) -> un obiect sau primitiv este aruncat într-un alt tip'


polimorfism - binding (linking)

legarea statică - tipul unui obiect este determinat în timpul compilării de către compilator
legare dinamică - tipul unui obiect este determinat în timpul rulării

Clase Abstracte si interfete

o clasă abstractă Java este o clasă declarată cu cuvântul cheie abstract care poate include metode abstracte
o metoda abstracta nu are implementare
clasele abstracte nu pto fi instnatiate in obiecte
referințele la clase abstracte pot fi utilizate pentru a defini parametrii în metode
toate metodele abstracte sunt mostenite si trbeuie definite in subclase
o clasă care implementează o interfață, dar care nu implementează toate metodele interfeței, trebuie declarată abstractă.

o interfață java este un tip de referință, similar cu o clasă, care poate conține numai
1) constante
2) metode abstracte fara implementare
3) metode default (implicite)
definit cu cuvântul cheie implicit la începutul semnăturii metodei
poate fi utilizat în cazul adăugării de noi funcționalități la o interfață, specificând o implementare implicită pentru noua metodă pentru a evita ruperea codului
4) metode statice (cu implementare)
5) metode private (cu implementare)

metode abstracte

toate declarațiile metodei interfeței sunt implicit abstracte și publice, cu excepția cazului în care sunt declarate statice sau implicite
metoda abstractă a unei interfețe sunt moștenite de clasele care implementează interfața și clasificate le înlocuiesc pentru a oferi o implementare

metode statice

declarația metodei statice conține modificator static (implicit public)
metodele statice dintr-o interfață nu sunt moștenite de clasele de implementare sau subinterfețele
există o singură modalitate de a apela la metoda statică a unei interfețe - folosind numele interfeței

metode default (implicite)

permit evoluția interfețelor existente
o metodă implicită poate fi adăugată la o interfață existentă pentru a furniza o implementare implicită a metodei
toate clasele care implementează interfața vor moșteni implementarea implicită
clasele pot alege să înlocuiască implementarea implicită


metoda implicită în interfață versus o metodă concretă a unei clase care implementează interfața
similaritati : amandoua vin cu o implementare, amandoua metode isi pot folosii parametrii si pot arunca exceptii.
deosebiri : accesul la starea obiectului, o metodă implicită nu are acces la instanța variabilelor clasei care implementează interfața, o metodă concretă poate accesa variabilele de instanță ale clasei, metoda implicită are acces la ceilalți membri ai interfeței, de exemplu alte metode, constante și membri de tip

metode private

nu este mostenita deci nu poate fi suprascrisa, si nici o metoda finala nu poate fi suprascrisa
o metodă implicită este o metodă de instanță și oferă o implementare implicită. este menit să fie supraîncărcata
puteți avea o metodă privată într-o interfață care este fie o metodă de instanță non-abstractă, care nu este implicită sau o metodă statică

interfete functionale

o interfata functionala este o interfata ce are doar o metoda abstracta
metodele statice și cele implicite nu sunt luate în considerare pentru a desemna o interfață sau o interfață funcțională
se poate pune inainte de declaratie @FunctionalInterface
compilatorul va verifica interfața adnotată conține într-adevăr o singură metodă abstractă, în caz contrar, declarația de interfață nu va fi compilată

interfete marker (marcator) -> interfete fara metode declarate (ex Serializable, Cloneable)

interfete - reguli

toate metodele declararile metodele abstracte într-o interfață sunt publice
interfetele nu pot fi instantiate
variabilele de referință pot avea ca tip o interfață, dar orice obiect atribuit acestora trebuie să fie instanțe ale unei clase care implementează interfața

C, C1, C2 sunt clase
I, I1, I2 sunt interfete
T, T1, T2 sunt tipuri (primitive / referinte)
C1 extinde C2 => C1 este un subtim de a lui C2
I1 extinde I2 => I1 este un subtip al lui I2
C implementeaza I => C este un subtip al lui I
pentru fiecare I => I este un subtim al obiectului
pentru fiecare T => T[] este un subtip al obiectului
daca T1 este un subtip al lui T2 => T1[] este un subtim al lui T2[]
pentru fiecare C care nu este obiect => C este un subtip al obiectului


moștenire în formă de diamant

interfata vs clasa abstracta

asemanari :

ambele definesc un contract care trebuie implementat de o clasă
interfata nu descrie rolul principal al clasei
clasa abstracta definește identitatea de bază a urmașilor săi
interfata specifica ce poate face clasa, nu si ce este.
subclasele unui clase abstracte sunt omogene
subclasele interfetei sunt heterogene

mostenire -> caracteristici principale

un utilizator ar trebui să studieze pentru a înțelege metodele superclasei sale
mai putin cod
operatiile sunt mai dificil de inteles
multe metode sunt deja implementate

dezavantaje

sparge încapsularea, deoarece expune o subclasă la detaliile de implementare a superclasei sale
legătura dintre clasa copilului și clasa părintească este stabilită în timpul compilării
este posibil ca subclasele să fie modificate dacă se modifică implementarea superclasei
implementările moștenite de la superclase nu pot fi schimbate la runtime ca blocuri de compoziție

agregare - avantaje
obiectele conținute sunt accesate de clasa conținând numai prin interfețele lor
incapsulare buna
compoziția poate fi definită dinamic la timpul de rulare prin obiecte care se referă la alte obiecte de același tip
dezavantaje -  sistemele rezultate tind să aibă mai multe obiecte
- interfețele trebuie definite cu atenție pentru a utiliza mai multe obiecte diferite ca blocuri de compoziție
concluzie (compozitie > mostenire)

obiective de proiectare poo

reutilizabitate, flexibilitate, generalitate (cu efort minim), extensibilitate
design patterns (DP) (modele de design ajuta la atingerea acestor obiective)

nivel inalt -> framework
nivel mediu -> design patterns
nivel scazut -> clase

soluții recurente pentru a crea probleme pe care le vedeți de mai multe ori
set de reguli care descriu modul de îndeplinire a anumitor sarcini pe tărâmul software-ului
un model de proiectare abordează o problemă de design recurentă care apare în situații de proiectare specifice și îi prezintă o soluție

modele de creație
ajuta la crearea obiectelor folosind niveluri de creare indirectă (subclase sau alte obiecte)

modele structurale
ajuta la compunerea grupurilor de obiecte în structuri mai mari

modele comportamentale
ajută la definirea comunicării între obiecte și, de asemenea, ajută la controlul fluxului programelor complexe

exemple modele de creatie :

abstract factory -> generarea de familii de obiecte înrudite sau dependente (obiecte de produs) fără a specifica clasa lor concretă

builder / constructor -> folosit pentru a genera obiecte compozite. Separa construcția unui obiect complex de reprezentarea sa, astfel încât același proces de construcție poate crea reprezentări diferite

factory method / virtual constructor -> definește o interfață pentru crearea unui obiect, dar permite subclaselor să decidă ce clasă trebuie să se instanteze. Permite unei clase să amâne procesul de instantanare subclaselor

prototype -> specificați obiectele pe care să le creați folosind o instanță prototipică și creați obiecte noi prin copierea acestui prototip

singleton -> crearea de obiecte unice dintr-o anumită clasă

exemple modele structurale :

adapter / adaptor ->  invelirea obiectelor într-o interfață nouă. Convertește interfața unei clase într-o altă interfață pe care o așteaptă clienții. Adaptorul permite ca clasele să funcționeze în alt mod, din cauza interfețelor incompatibile

bridge / pod -> decuplează o abstractizare de la punerea în aplicare a acesteia, astfel încât cele două să poată varia independent

composite -> compune obiecte în structuri de arbori pentru a reprezenta ierarhii parțiale. Composite permite clienților să trateze uniform obiecte individuale și compoziții de obiecte

decorator -> atașează responsabilități suplimentare unui obiect într-un mod dinamic. oferă o alternativă flexibilă la subclase pentru extinderea funcționalității

facade / fatada ->  furnizeaza o interfață unificată unui set de interfețe dintr-un subsistem. Fațada definește o interfață de nivel superior care face mai ușor utilizarea subsistemului

flyweight ->  utilizeaza distribuirea pentru a susține eficient un număr mare de obiecte cu granulație fină

proxy / imputernicirea ->  furnizează un surogat sau un locatar pentru un alt obiect care să controleze accesul la acesta. utilizat pentru accesarea obiectelor la distanță sau costisitoare

exemple modele comportamentale

command -> încapsulează o solicitare ca obiect. folosește obiecte pentru a reprezenta operațiunile

chain of responsibility / lanț de responsabilitate -> evită cuplarea expeditorului unei solicitări la receptor. Definește un lanț de obiecte care au dreptul să cunoască și să proceseze solicitarea până când un obiect o gestionează. obiectul care va procesa solicitarea nu este cunoscut la momentul proiectării

iterator -> încapsulează modul în care cineva traversează și accesează componentele unui obiect agregat

interpreter / interpretor -> pentru o anumită limbă definește o reprezentare a gramaticii sale și un interpret pentru utilizarea gramaticii pentru a interpreta propozițiile limbii

mediator -> încapsulează protocolul dintre un ansamblu de obiecte care au cooperat pe la colegi (în loc să-i permită pe colegi să definească referințe între ele - cuplare puternică). Obiectul mediator asigură indirecția necesară pentru cuplajul liber

memento -> surprinde și externalizează o stare internă a unui obiect. În acest fel obiectul poate fi restaurat la această stare din urmă.

observer -> definește dependența între obiecte și multe. când un obiect schimbă starea, toți dependenții săi sunt notificați și actualizați automat

state -> reprezentarea și procesarea stărilor ca obiecte

visitor / vizitator -> reprezintă o operație care trebuie efectuată pe elementele unei structuri a obiectelor

template method -> definește un schelet al unui algoritm într-o operație, postoponând câțiva pași către subclase. partea invariabilă a algoritmului ar trebui să fie implementată prin metoda tempalte și comportamentul care variază este implementat de subclase

strategy / strategie -> incapsuleasa un algoritm

ADAPTER / ADAPTOR / INVELITOR

adaptorii -> permit claselor să funcționeze care altfel nu ar putea fi din cauza interfeței incompatibile
exemplu : un player audio care poate functiona doar cu fisiere mp3 si vrea sa foloseasca un program capabil sa functioneaza cu mp4.

intentia : transformă interfața unei clase într-o interfață care poate fi utilizată de o altă clasă
doriți ca un client să apeleze la o metodă a unui obiect instant al unei clase care nu implementează interfața

de ex avem un client care apeleaza o metoda request() din clasa tinta
clasa tinta este adaptata cu ajutorul interfetei (adapter) si va pointa catre metodele specifice din adaptee.

consecinte : adaptor lucreaza cu mai multi adaptee
adaptorul poate adauga functionalitate in clasele adaptee

modelul command
intentia : foloseste obiectele sa reprezinte operatii / comenzii
consecinte : comenziel pot fi tratate si manipulate ca niste obiecte. un sir de comenzi poate fi reprezentat ca si o coada, stiva sau alte structuri de date.

avem un invoker (o telecomanda) care poate avea una sau mai multe interfete (comenzi) implementate in clasa command iar receiverul foloseste clasa command pentru a primi modificarile

invoker ->  o clasă din acest rol creează obiecte de comandă concrete dacă trebuie să invoce o comandă

deci -> se decuplează obiectul care invocă operația de cel care știe să-l efectueze

composite design pattern
(modelul compozitiei recursive)
prezinta o clasa abstracta care reprezinta primitivele si compusele.


definește ierarhiile de clase constând din obiecte primitive și obiecte compuse
obiectele primitive pot fi compuse în obiecte mai complexe care, la rândul lor, pot fi compuse, etc.
clienții, în mod normal, nu știu (și nu ar trebui să le pese) de ce au de-a face cu o frunză sau o componentă compozită -> se simplifica codul
facilitează adăugarea de noi tipuri de componente. Subclasele de compozite sau frunze noi și definite funcționează automat cu structurile existente și codul client. Clienții nu trebuie schimbați pentru noi clase de componente

metoda factory

avem o aplicatie care luceaza cu niste documente. acest factory doreste ca aplicatia sa nu fie hardcodata, sa nu fie legata direct de documentele cu care lucreaza, nu aplicatia respectiva sa invoce new pe documentul pe care vrea sa-l utilizeze. sa apeleze la o fabrica de documente si acea fabrica sa produca respectivul document.
vrem sa decuplam o clasa de entitatile pe care le utilizeaza. sa i le creeze altcineva pentru ea.

avem o aplicatie si o interfata sau o clasa abstracta documentfactory si o clasa care implementeaza metoda createdocument definita in interfata (documentfactory) si aplicatia cere acestui factory (request creation) sa ii creeze un document cu care sa lucreze. aplicatia va primi o referinta a documentului creat

acest model de metodă furnizează unui obiect independent de aplicație un obiect specific aplicației la care poate delega crearea altor obiecte specifice aplicației

product -> superclasa abstracta a obiectelor produse de factory method

interfata factory -> aplicație independentă clasă abstractă sau interfață

un exemplu : creationrequester care este factorypatterndemo care cere shapefactory sa creeze obiecte care sunt subclase ale lui shape. creationrequester e clasa cu metoda main care interactionaza cu shape

design patter proxy (model proxy)

(reprezinta niste entitati mai complexe) (un proxy este un surogat, un reprezentat al cuiva)
anecdota comunism : ce este sampania? sampania este bautura pe care o beau masele populare prin reprezentatii lor (prin proxy lor)

clientul in primul rand se adreseaza proxy, iar daca proxy nu poate sa raspunda atunci trimite acea cerere spre serviciul adevarat.

clienții proxy nu știu că au de-a face cu un surogat în locul obiectelor reale de care au nevoie
clasa proxy și clasa pe care o reprezintă (serviciul clasei) au aceeași interfață sau aceeași superclasă

daca am o aplicatiei care se executa local si cere executia unei metode de pe un svr indepartat. mai intai cere operatia respectiva proxy-ului local. acesta verifica parametrii (verifica daca sunt de tipul cerut) (nu mai are rost sa se mai trimita spre retea acele date pentru ca eroarea poate fi data de proxy)
astfel se salveze sau se economiseste transmiterea pe retea a datelor (trimiterea dus-intors pe retea este scumpa)
obiecte scumpe (constructia lor ia multe resurse si mult timp)
daca proxy-ul poate sa raspunda atunci raspunde.

in cazul in care se utilizeaza un site. de multe ori pagina respectiva este memorata intr-un cache local a.i nu mai este adusa pagina dintr-un site indepartat ci dintr-un cache local numit proxy

avem o interfata de tip imagine (implementata atat de o imagine reala cat si de o imagine proxy) daca imaginea este deja in proxy adica in cache este adusa de acolo, daca nu se merge dupa imaginea reala, oriunde s-ar afla ea)

prin această indicație, obiectul client nu este conștient de faptul că obiectul de serviciu nu a putut fi creat atunci când operația este invocată și procesată de obiectul proxy

modulul singleton

in multe situatii avem obiecte unice (o masina are un singur volan) (un calculator are un singur sistem de operare). datorita faptului ca avem situatii multe in care trebuie sa creem un singur model.
cum creem o singura instanta dintr-o clasa
numele metodei care creeaza instanta unica se numeste instance.
pattern-ul singleton pt implementarea lui necesita ca limbajele de programare sa poata defini date statice.

clasa singleton defineste referinta oneObject la un singur obiect
constructorul clasei este de tip private
si metoda instance este generatoarea obiectului unic
daca oneObject e null (nu a fost generat) se apeleaza constructorul este ok daca e privat il apelez dintr-o metoda proprie clasei.

se genereaza eroarea daca apelam Singleton s = new Singleton(); (constructorul este privat)

cealalta varianta este folosind exceptii
clasa singleton arunca singletonexception i ncazul in care se incearca crearea unui alt obiect de tip singleton.
clasa singleton ascunde singura operație de creare a insatenării în spatele unei metode de membru static

inversiunea controlului

fundamentala in dezvoltarea aplicatiilor software moderne.
se inverseaza diferite tipuri de controlare in poo (fluxul unui aplicatii, fluxul crearii de obiecte)
toate cu scopul de a avea clase care sunt mai putin cuplate pentru a putea fi mai bine testate, mai bine intretinute si mai extensibile

inversion of control poate sa fie implementat in 3 moduri
1) tehnici numitie injectie de dependinte
2) tehnici de tip locator
3) tehnici de tip callback

1) injectare de dependinte
o clasa a si o clasa b
pentru ca sa avem clasa a utilizand clasa b avem 2 modalitati
in primul caz (dependenta hardodata) -> clasa a creaza direct obiectul b de care are nevoie (controlul este la nivelul clasei a) (fie il creeaza direct fie prin intermediul unui factory method)
in celalalt caz o entitate externa este in controlul generarii elementului de tip b de care are nevoie clasa a. in constructorul clasei a, obiectul de tip b este injectat in constructor de catre o entitate exterioara.
aceasta injectie poate fi fie cu parametru in constructor fie cu metode de tip set.

clasa myprogram are metoda main in care creeaza o variabila de tip client si injectieaza serviciul in client new Client(new Service(..));
serviciul implementeaza o interfata IService cu metoda serve()
clientul apeleaza start, executa serviciul. deci myprogram genereaza clientul injectand serviciul in client

2) service locator (locatoare de servicii)
un locator de serviciu e un software care permite dezvoltarea de cod slab cuplat
daca am un program care are nevoie de un serviciu si nu stie unde sa il gaseasca -> foloseste un locator.
in tehnica anterioarea myprogram cunostea serviciul, aici myprogram nu cunoaste exact serviciul (tehnica fundamentala pentru arhitecturile SOA (Service Oriented Architecture)

myprogram cere clientului sau sa-i rezolve o problema, generand un nou client, parametrii indica problema de rezolvat, clientul folosestii respectivii parametrii pentru a apela un locator care sa-i localizeze un serviciu care stie sa-i rezolve problema respectiva. locatorul localizeaza serviciul si il injecteaza. in client.start() are deja clientul serviciul injectat si il executa.
SL = Service Locator
parametrii aceia pot fi de tipul quality of service (cat de rapid sa fie sau cat de rapid sa se execute).

service oriented architecture (SOA)

un service provider (furnizor de servicii) (poate fi o intreprindere) isi inregistreaza serviciile disponibile intr-un broker (care va functiona ca si un SL service locator). acesti service provider pot fi diferite firme (transport, warehouse, acomodare) si vin pe urma niste clienti, care pot fi tot firme sau persoane fizice si cauta niste servicii. cautarea este facuta pe baza acestui locator. i se returneaza customer-ului cel mai bun serviciu. ii va returna customerului acesta si lasa pe customer sa invoce serviciul respectiv al provider-ului.

neajunsurile abordarilor DI si SL (dependency injection si service locator)
rezulta din hardcodare (un utilizator care doreste sa utilizeze DI si SL trebuie sa isi gestioneze sigur dependintele) management-ul acestor dependinte este dificil daca sunt prea multe
daca vrem sa modificam o clasa se depinda de alta noua, toate aceste modificari trebuie facute cu mana, recompilat. putem sa avem de a face cu sisteme cu sute/mii de asemenea dependinte intre clase. este necesara o automatizare a acestor dependinte

solutia ? containere cu management automat (framework spring care foloseste un IoC container pt managementul automat al dependintelor).

3) IoC (inversion of control cu callback)

 obiectivul este sa informam o clasa ca intr-o alta clasa s-a intamplat un eveniment.
sa apelam o alta functie dintr-o clasa care sa se execute atunci cand un eveniment se intampla intr-o alta clasa.

tehnica folosita in java pentru programarea bazata pe evenimente in care functia chemata de alta clasa este de fapt listener-ul sau handler-ul de evenimente.

callback -> o functie/metoda f care este transmisa ca argument unei alte functii g si f se asteapta sa fie executata dupa ce s-a intampla un eveniment la nivelul functiei g (definitia corecta a callbackului)
este utilizata in task-uri asincrone (dar in java non-functional metodele nu pot sa fie pasate ca parametri).
dar folosind expresii lambda putem pasa acest lucru.

exemplu : interfata IF defineste metoda f() care trebuie sa se execute la callback, avem un listener care implementeaza interfata (arata cum este implementeaza metoda f) si pe urma avem o aplicatie care functioneaza pe post de notifier (notifica listener-ul cand se intampla ceva, care include o referinta de tip interfanta si o metoda de inregistrare a functie de callback si o metoda de buisness in care se intampla evenimente.

main-ul instantiaza un listener, instantiaza o aplicatie, inregistreaza cu aplicatia listener-ul dupa care zice sa se execute operatie de buisness. in timpul situatie de buisness se intampla acest eveniment, si folosind aceasta referinta inregistrata se apeleaza listener-ul handler-ul care stie sa trateze situatie care s-a creat in timpul executiei buisness. (butoane la GUI de ex)

Observer design pattern

acest design este utilizat atunci cand avem dependinte one to many -> atunci cand partea one se modifica, dorim ca si partile many asociate cu partea one sa fie informate ca sa se poata modifica

avem o serie de observatori care in momentul in care se modifica o valoare dintr-un array, se asteapta sa fie informati pt a putea modifica reprezentarea grafica a dependentei respective (cum se schimba un grafic in excel)

daca avem un warehouse , un depozit de legume si fructe (partea one) partea many ar fi niste magazine de cartier care se aprovizioneaza de la depozit. acele magazine vor sa fie informate in anumite momente.
asta face design pattern-ul observer
realizeaza aceasta dependinta one to many si instiinteaza componentele many ori de cate ori se modifica elemente din partea one (se mai numeste si publish - subscriber) (unul publica iar celalalt este abonat)

componenta one este subiectul (subject) iar componenta many sunt observatorii
clasa abstracta subiect are metodele de atasare si detasare de observator si notify.
ea este subclasificata de catre subiecti concreti
subiectii concreti definesc metodele getState() si setState() si au o variabila de instanta subjectState (cate tone de banane, sau au venit banane). metoda notify este apelata de fiecare data cand se executa metoda setState() dintr-un subiect concret. in momentul in care a sosit camionul si a descarcat se actualizeaza cu noul tonaj descarcat iar in setState vom gasi un apel la notify. Observer are o lista de observatori. pentru toti observatorii din acea lista apeleaza metoda update definita in clasa observer.

observatorul concret are o referinta la subiectul pe care il monitorizeaza, pentru ca metoda update foloseste aceasta referinta pentru a afla de fapt ce s-a intamplat cu subiectul pe care il urmareste.

daca am un observator care e interesant pe mai multi subiecti.
nu putem sa luam acest schelet si sa il punem direct in acea aplicatia fara sa adaptam. cine activeaza activarea, cine e responsabil de acel triggering? cat de multa informatia e transmisa de la subiect la observator?

model push -> toate modificarile subiectului sunt impinse spre observator
model pull -> observatorul este informat numai ca s-a informat ceva si lasat sa-si treaca singuru caracteristicile care il intereseaza.
se furnizeaza suport sub forma unui clase Observable si a unei interfete Observer
incepand cu java 9 aceste structuri sunt deprecated (adica java nu le va mai considera pentru a fi utilizate in dezvoltarile lor)

se poate implementa de la 0 acel design pattern (fara a folosi clasele si interfetele deprecated)
alta varianta -> property change listener (o interfata definita in Java Beans)

Observable a fost date unei clase si nu interfetei, iar numele interfetei este Observer (trebuia sa fie pe dos) (ii iertam haha)
interfetele ar trebui sa se termine cu -able

interfata Observer defineste metoda update
clasa Observable defineste o variabila instanta state si un constructor care construieste un obiect Observable fara observatori.
defineste metodele addObserver, deleteObserver si notifyObservers.
notify este apelat de fiecare dat cand se executa setState() si apeleaza update, pasand niste argumente
notifyObservers ia ca si parametru un obiect (variabila de instanta care s-a modificat) (pretul sau cantitatea de ex) si apeleaza metoda update definita de observator si paseaza this (ascuns) care inseamna de fapt referinta la subiectul concret si parametrul care s-a modificat (pretul , cantitatea de ex)
notify fara parametru, spune numai observatorului ca s-a modificat si lasa observatorul sa traga singur de ce are nevoie (pret sau cantitate)
mai apar 3 metode, hasChanged, setChanged si clearChanged() care lucreaza pe variabila instanta state
hasChanged returneaza valoarea lui state. valoarea lui state e modificata cand se apeleaza setChanged(). clearChanged() este o metoda care intoarce state-ul pe fals si se executa automat de fiecare data cand se executa notifyObservers. adica dupa ce acestia sunt notificati, se pune pe fals.
setChanged si clearChanged sunt declarate protected !

interfata Observer defineste metoda update, care are ca parametri obiectul subiect (care s-a modificat) si cea variabila de instanta din subiect s-a modificat (pret sau cantitate)

public class Item extends Observable (bananele din warehouse)
defineste variabile de instanta nume, stocul si pretul
constructorul si metodele get pentru fiecare instanta si metodele set
metodele set sunt importante pentru ca acolo vine camionul, a venit camionul a descarcat o noua cantitate q pe care o folosim pt a actualiza stocul si apelam setChanged() adica spunem ca s-a modificat stocul si apelam notifyObservers cu noul stoc trimis ca argument.

delegare : clasa item contine o instanta Observable -> toate comportarile care vor fi legate de observable vor trebui delegate spre aceasta referinta. (inca nu e posibila o asemenea abordare)
variabila state e controlata de metodele setChange si clearChanged care sunt PROTECTED (ele nu pot fi interogate de obiecte externe, pentru ca nu sunt publice)

solutia? definim o subclasa a lui observable definita observabletype si sa suprascriem metodele setChange si clearChange ca si public (este posibil pentru ca din design by contract, atunci cand subclasificam, accesul in sublcase trebuie sa fie mai permisiv decat accesul in superclase)

eroare de securitate, exista o metoda publica de a obtine observatorii (pt a adauga noi observatori) (cand cineva public poate sa adauge si sa stearga observatori)

se defineste un safeItem care extinde Item -> renuntam la returnarea getObservable si putem controla noi din interior cum se sterg (prezinta metodele addObserver si deleterObserver astfel nu sunt controlate de un program driver)

FRAMEWORKS

framework-ul ne da o solutie globala pentru un set de tipuri de probleme.
framework-ul poate fi prevazut ca si o aplicatie semi-completa adica e dezvoltata pana de la un punct, si de la un punct incolo utilizatorul o customizeaza si o aplica.

cele mai populare frameworkuri sunt cele pt dezvoltarea aplicatiilor web
pentru java -> spring
pe pythong -> jungo

pt a usura munca de development se utilizeaza astfel de framework-uri in momentul in care nivelul de complexitate este mai mare. din perspectiva modului si a tehnicii de programare utilizate in cadrul frameworkului, orice framework se bazeaza pe IoC (responsabilitatea instantierii unui obiect va reveni frameworkului) el va fi cel ce instantieaza obiectul respectiv, instantierea se face cu DI. se folosesc functii de lookup pt a cauta dependente specifice care ar trebui sa fie injectate

ce contine un framework? deobicei va contine un set de clase (care sunt predefinite pt anumit functionalitati), un set de interfete. deobicei extindem clasele si le specializam si definim metodele de interfete. si un set de design pattern-uri care faciliteaza dezvoltarea de solutii generice si reutilizabile. utilizand tehnicile de programare utilizate pana acum, ceea ce facem noi in interiorul unui framework e sa transformam solutia generica intr-o solutie specifica domeniului pe care vrem noi sa il modelam. ca si principal scop e sa reutilizam cat mai mult cod si sa facilitam rapiditatea in dezvoltare a unor aplicatii. promoveaza reutilizarea codului si in acelasi timp este extensibil si se poate specializa foarte usor pentru tipul de aplicatie.

exemplu javaswing (poate fi vazuta ca un framework decat o librarie) un framework care ajuta crearea structurilor de interactiune cu frontend-ul unei aplicatii java si sa le administrezi.
se ofera un set de interfete, un set de clase predefinite, ceea ce trebuie facut e sa extindem functionalitatea si sa o specializam pentru aplicatia noastra.

din perspectiva cantitatii de cod reutilizata, in cazul design pattern, cantitatea de cod e mai mica decat in cazul unui framework. nivelul de reutilizare e mai mic.
framework-urile sunt specifice unui domeniu de aplicatie, pe cand design pattern-urile sunt specifice oricari tip de aplicatie (pentru o problema specifica)

diferenta intre framework si librarie
in cazul in care utilizam o librarie este responsabilitatea programului sa instantieze librarie respectiva
in cazul in care utilizam un framework se utilizeaza tehnica de IoC si in cazul asta e responsabilitatea frameoworkului sa instantieze un obiect in program si in cazul acesta se utilizeaza DI pentru a facilita acest lucru.

tehnici noi introduse in java o data cu java 8 (expresii lambda si interfete functionale)

un model de calcul devenit foarte popular in ultimul timp -> modelul de programare functional
presupune dezvoltarea de functii si se bazeaza pe lambda calculus, si modalitate de implementare bazata pe trasarea starilor
din perspectiva functiilor, ele nu sunt noi si programarea functionala exista de mult timp (Haskell)
introducerea calculului paralel -> sunt multe calculatii care doresc sa proceseze cantitati mari de date, exista si capacitati hardware mult mai mari si pentru a putea fi exploatate e foarte de dorit ca programul facut sa poata sa rulez pe mai multe calculatoare/servere in paralel.
programarea functionala are niste beneficii care faciliteaza parelelizarea rularii unui soft (atat la nivelul mai multor calculator, cat si mai multor core-uri)
programele oop din perspectiva timpului de executie, sunt mai lente.
au aparut asa numitele limbaje impure, care presupun amestec de concepte oop (cea mai mare parte e oop totusi), dar peste oop s-au introdus niste concepte si paradigme specifice programarii functionale, tocmai pentru a putea beneficia de avantajele aduse de programarea functionala, principalele caracteristici ale programarii functionale -> modalitatea de scriere a codului (declarativa)

model de scriere a codului declarativ -> pentru a controla codul, se bazeaza exclusiv pe functii si mai putin pe elemente specifice (if case switch break). principalul avantaj e dat de faptul ca fiind declarativ, cantitatea de cod este mult mai mica (codul e mult mai concis)
promoveaza imutabilitatea -> a crea obiecte imutabile e o cerinta foarte importanta in momentul in care se dezvolta o aplicatie oop -> te scuteste de multe probleme si te ajuta sa pastrezi si sa localizezi cat mai bine impactul pe care bug-urile le pot avea in sistem. alta cerinta este evitarea side-effects (unul din principalele mod de a da seama daca o metoda e implementata corect este studiul efectelor secundare) (by default rolul unei metode e sa modifice starea unui obiect), dar in programarea functionala metodele definite sunt fara side-effecturi. singurele modificari care au loc sunt modificari care au loc in corpul metodei respective si asupra tipului de return, deci nu au efect asupra unei stari globale ale aplicatiei respective.

ofera suport pentru high-order functions (niste functii speciale care pot fi transmise ca si parametru in alte metode) (se transmite ca si parametru secvente si blocuri de cod) (principalul motiv este pentru a face codul cat mai concis, cu cat mai putine linii de cod) (probabilitatea de a aparea bug-uri devine mai mica si se usureaza intelegerea) (din perspectiva celor 2 stiluri de progamare, imperativ si declarativ)

in limbajul imperativ controlul (flow-ul de control) este dat de for, if, break, case, else (foarte multe tipuri de flow-uri de control), in cazul limbajului declarativ controlul se utilizeaza prin intermediul unor functii (contains). principalul avantaj al unei astfel de abordari este dat de faptul ca functiile respective pot sa proceseze colectiile intr-o maniera imutabila si mai mult, cei care furnizeaza functiile respective, pot sa se implementeze intr-o asa maniera a.i sa fie utilizate intr-o maniera paralelizata pe mai multe programe.

in buisness, va depinde de politica firmei daca promoveaza sau nu utilizarea obiectelor imutabile, sunt firme in care exista reguli speficice de calitatea codului. variabilele de clasa trebuie sa fie definite ca si final, nu trebuie sa avem metode de set definite si trebuie sa avem grija inclusiv la get pentru ca la get daca tipul de date returnat e un tip de date imutabil, folosind un get se poate modifica totusi starea obiectului prin deviatie (modifc starea unei variabile care-i imutabila). tipurile de date ale variabilelor sa fie pe cat posibil obiecte imutabile, daca nu sunt ar trebui ar trebui returnat copii in get (se face un shallow copy a variabilei respective care va fi returnata)

functiile de nivel inalt sunt functii care pot lua ca argumente alte functii ca si argument.
expresie lambda -> fragment de cod anonim, avem o lista de parametrii, se foloseste ->
o expresie lambda nu arunca exceptii, nu are nume, nu are clauze de return si nu se poate utiliza tipul generic intr-o expresie lambda.

interfete functionale -> o singura metoda abstracta si oricate alte metode statice, private si default.
in programarea functionala nu este importanta ordinea executiilor statement-urilor.

intotdeauna blocul de cod se va mapa peste o intrefata functionala si avand in vedere ca interfata functionala respectiva are o singura metoda abstracta, fragmentul de cod va defini corpul metodei abstracte respective, deci lambda body va deveni corpul metodei abstracte din interfata functionala.

e foarte important ca administrarea expresiilor lambda sa se faca prin interfete functionala, pentru a sti compilatorul sa incerce sa mapeze body-ul peste metoda respecitva (avem nevoie de o metoda abstracta)

expresie explicita -> tipul de date a parametrilor e specificat in mod clar (int, String, orice tip de date)
maniere implicita -> nu se specifica tipul de date, si atunci compilatorul va determina tipul de date in functie de contextul in care va fi apelat, in functie de parametrii de intrare a metode abstracte din interfata functionala peste care se va mapa. (comportamente diferite in contexte de mapare diferite)

in momentul in care avem expresii lambda in care nu am specificat tipul, pentru a infera tipul respectiv, compilatorul executa o secventa de pasi (pt a reusi sa dezambiguizeze codul expresiei lambda). din perspectiva modului de utilizare, pentru a o putea mapa pe o interfata functionala, intotdeauna o sa am un tip de interfata functionala  T t = <LambdaExpression>

cum ajunge sa mapeze corpul undei metode abstracte? o secventa de 6 pasi. intotdeuna tipul T trebuie sa fie o interfata functionala. primul pas pe care il face compilatorul java e sa verifice ca tipul dat T este o interfata functionala. mai departe incearca sa mapeze input-ul sau parametri expresiei lambda peste header-ul metodei abstracte, se uita la metoda abstracta din interfata functionala T sa vada daca numarul de parametri se potriveste cu numarul de parametri din expresia lambda si daca expresia lambda ii explicita inseamna ca avem un map si fiind un map atunci va utiliza corpul expresiei lambda ca si corp a metodei abstracte respective. daca avem un match, verifica sa vada ca clauzele aruncate in context sunt compatibile cu clauzele potentiale definite in cadrul metodei abstracte si daca totul se potriveste, incluziv clauzele aruncate la run-time avem un match perfect si corpul expresiei lambda va deveni corpul metodei abstracte, deci expresia lambda va implementa intr-un fel interfata functionala, ii va da o implementare care se va utiliza ulterior.

behaviour parametrization -> comportamentul unei clase este modificat in functie de fragmentul de cod care este transmis ca si parametru intr-o metoda. in functie de fragmentul de cod si corpul expresiei lambda ce se transmit ca si parametru, comportamentul unei metode se va schimba. devine posibila din cauza faptului ca expresiile lambda sunt de fapt functii de nivel inalt, a caror comportament e preluat din programarea functionala.

din cauza faptului ca parametrii si corpurile lambda, nu au intotdeauna in mod explicit tipul de date definit, in mod clar ajungem la supraincarcarea metodelor si definirea de comportomante polimorfice. in cazul asta compilatorul trebui sa dezambiguizeze codul, sa incerce sa isi dea seama de tipul de date si tipul de metoda peste care se va mapa call-ul respectiv, metoda respectiva, pentru a-i putea da corp. ordinea de dezambiguizare : mai intai se uita la tipul de parametrii, daca e implicit clar se mapeaza nr de parametri si tipul de date exact, daca tipul de date nu e exact se poate utiliza un cast si ca o regula de a ajuta compilatorul sa dezambiguizeze informatia, se recomanda ca blocurile de cod lambda sa fie asignate inainte (explicit)

assignment-ul se poate face in functie de context :
se poate face in contextul invocarii de metoda
return context -> tipul de return sa fie inferat prin executia unei expresii lambda sau poate fi utilizat intr-un contest de cast, in care cast-ul sa fie cast-uit la o interfata functionala pe care se poate mapa.

interfetele funtionala penru un comparator : chiar daca interfetele lambda in corpul lor nu pot utiliza parametri generici, nu este nici o constrangere asupra interfetei si metodei abstracte. interfata si metoda abstracta pot sa utilizeze tipuri generice. tipul generic e un tip care ajuta compilatorul in a dezambiguiza anumite statement-uri si il ajuta mai ales sa faca verificari de tip la compile-time.

la run-time compilatorul va inlocui tipul generic cu tipul specific inferat, deci tipul generic are o importanta foarte mare la compile-time, de aceia la tehnica i se spune type eraser.

interfata functionala mapper<t> avem o metoda abstracta map si o metoda statica care face un mapToInt, metodele statice pot sa vina cu functionalitati. din perspectiva tipului de date asteptat in mapToInt avem o expresie generic, trebuie sa fie un supertip al tipului U, atunci compilatorul la runtime va verifica intotdeauna ca tipul de date trebuie sa fie supertip al lui U.

daca vreau sa definesc o expresie lambda care sa se mapeze si peste o interfata functionala si peste o interfata marker pot folosi intersectia de tipuri, folosind & expresia lambda se va mapa peste interfata functional si va beneficia si de proprietatea de marker adusa de interfata Serializable. fragmentul de cod generat va implementa ambele interfete.

platforma java a definit un set de interfete functionale. interfata Function care aplica o functie care va veni printr-o expresie lambda, o va aplica asupra unui tip T si va returna un raspuns. BiFunction la fel numai ca va aplica functia peste 2 parametri.
Predicate evalueaza un predicat pe care il primeste ca si input.
Consumer consuma un tip de date si nu returneaza niciun rezultat -> utilizat cand vreau sa utilziez expresii lambda care fac print de informatii
Supplier-ul returneazaza o valoarea -> procesarea unui informatii si returnarea unei valori.

interfata function.

are 3 metode in ea (o metoda abstracta, metoda de apply (aplica functia)) si mai multe metode default care ajuta la implementarea metode apply care furnizeaza functionalitati suplimentare, cum ar fi compose (compunerea functiilor). andThen permite aplicarea functiilor succesive. super reprezinta intotdeauna un supertip a lui t iar extends un subtip a lui t
<? super T> -> SUPERTIP a lui t
<? extends T> -> SUBTIP a lui t

square.andThen(addOne) si avem 5 -> 5 * 5 + 1 -> 26
squeare.compose(addOne) si avem 5 -> (5 + 1)^2 -> 36

pe langa functia generica function exista si functii nongenerice (functii definite pentru fiecare tip de data in parte)

interfata predicate

verifica valoarea de adevar a unui predicat care va fi definit printr-o expresie lambda. exista metode care ne permit sa facem and / or / isEqual.

interfata Consumer

nu returneaza nicio valoare -> se utilizeaza pentru expresii lambda care consuma informatii, dar nu returneaza niciun tip (pentru imprementarea de print-uri).

interfata Supplier

implementeaza un get, rolul ei e sa returneze o valoare si se foloseste de fiecare data cand o variablia trebuie returnata, pentru a implementa un salut. poate fi implementata in fiecare caz in care nu avem niciun parametru de intrare pe expresia lambda.

method reference -> se utilizeaza folosind doua puncte si are rolul de a apela o metoda, nu-i un tip nou de date si nu e un pointer la o functie; e doar o modalitate de a explica o metoda care sa se execute. vrem sa se execute metoda length pe un string. vreau sa apelez metoda length a clase string. scrierea e mult ma iconcisa si mai usor de inteles pt a specifica tipul de date folosind method reference exista mai mutle modalitati.

stream

secvența elementelor de date
operațiunile de flux pot fi executate secvențial sau în paralel
Stream<T> -> operații pe secvența de elemente care susțin operații de agregare secvențiale și paralele
(collect, count, empty, filter, forEach, iterate, generate, limit, max, min, of, reduce, skip, sorted)
Collector<T,A,R> -> operație de reducție mutabilă (acumulează elementele de intrare T într-un container mutabil A; R este tipul rezultat al operației de reducere.
stream-urile nu sunt colectii
o colecție deține toate elementele în memorie
doar o parte a stream-ului este prezenta in memorie (elementele lui sunt calculate cand este nevoie de ele)
streamurile consuma date din collecti
fluxurile se concentrează pe calcule agregate pe elemente de date dintr-o sursă de date care ar putea fi colectate
colecțiile necesită o iterație explicită asupra valorilor sale
cu fluxuri, iterația este implicită în operațiuni (fluxurile sunt iteratoare inteligente peste colecții)
 stream-urile permit scrierea unui cod care este :
declarativ (concis si sigur)
flexibil
paralelizabil (performanta mare)
pipelined ->  multe operații de flux returnează un flux, permițând astfel operațiunile să fie înlănțuite în pipeline-uri mari.
un pipeline de operatii poate fi vazut ca o interogare a unei baze de date pe o sursa de date

fluxurile nu au stocare
un flux își trage elementele dintr-o sursă de date care poate fi o colecție sau o funcție care generează date

ex : calculul sumei patratelor numerelor impare
external iteration (iterator object) -> while(it.hasNext())
external iteration (for each statement) -> for
iteratie externa ->  clientul programului scoate valori din colecție și le procesează unul câte unul pentru a obține rezultatul
produs prin codul de execuție secvențial care poate fi executat doar de un singur thread.

iteratia interna -> foloseste fluxuri (streamuri)
int sumSqOdd = numbers.stream().filter.map.reduce

tipuri de operatii cu stream-uri / fluxuri

operatii intermediare (sau lenese)
preia elemente dintr-un flux de intrare și transformă elementele pentru a produce un flux de ieșire

operatii intermediare (sau dornice) ia elementele dintr-un flox si produce rezultatul

fluxul este în mod leneș până când apelați o operație de terminal pe acesta

operații intermediare
au alt stream ca tip returnat
permit operatiilor sa fie conectate intr-o interogare
operațiunile intermediare nu efectuează nicio prelucrare până când nu este invocată o operație de terminal pe fluxul pipeline , sunt operații leneșe
exemple de operatii intermediare (filter, map, distinct, sorted, peek, limit, etc)

operatii terminale
operatiile terminale pe un flux produc o valoare ce nu este flux (o colectie, un tip primitiv sau nicio valoare)
sunt precedate de operatii intermediare
exemplu : forEach, collect, count, toList, toArray, min, max, etc.)

operatia terminala forEach
execută o acțiune asupra fiecărui element al unui flux considerat consumator

operatiile terminale sum max min average etc.
citesc valorile dintr-o colecție și determina numărul total de caractere

operatia terminala - reduce
utilizat atunci când este necesar pentru a reduce un flux la o singură valoare, cum ar fi calculul produsului sumei, minimului etc (de ex suma tuturor valorilor ar fi .reduce(0,(c1,c2) -> c1 + c2);

operatia terminala - collect

caz special de operare de reducere numit reducere mutabilă
returnează un container cu rezultate mutabile, cum ar fi o listă, un set sau o mapare, așa cum este indicat de colectorul furnizat.
interfata Collector <T,A,R>

T - tipul de element care este procesat de flux și urmează să fie colectat
A - tipul containerului rezultat rezultat care continuă să obțină elemente (de tip T) adăugate pe parcursul procesului de colectare
R - tipul containerului rezultat sau colecția care este returnată înapoi ca o ieșire finală de către colector

membrii interfetei Collector sunt folositi de 4 componente
Supplier -> furnizează instanță sau instanțe goale de tip A pentru a începe acumularea de elemente
acumulatorul folosește o instanță a lui A pentru a colecta T
Combiner-ul -> combină două rezultate parțiale acumulate de tip A pentru a produce o instanță combinată de A
Finisher-ul -> mapeazaz A in R folosind o functie de mapare.

Intrebari

When an array of boolean elements is created, its elements are
assigned to the default value false

Which statement about (static) variables is correct
there is only one copy of each class variable that is shared by all instances of the class
a class variable does not need an object instance to use it without

A method that is associated to an individual object is called instance method

Consider the following declarations :
Interface I {}
Class B {}
Class D extends B implements I
which of the following object instantiations are correct?
I o2 = new D();
B o5 = new D();

What is true about a class constructor?
It may be overloaded
It is called with the new operator

Which statement is true about the class shown below?
public class TestPT1()
{ public void m1() {}
  public static void main(String args[])
 { m1(); }
}
It will not compile because m1() is not static

Which statement is true about the order of methods in a class
The methods can be listed in any order

What is the output of the program below
interface A {}
class C{}
class D extends C{}
class B extends D implements A

class TestPT2 {
public static void main(String args[])
{
	B b = new B();
	if(b instanceof A) System.out.println("b is instance of A");
    if(b instanceof C) System.out.println("b is instance of C");
}
b is instance of A b is instance of C

Point[] p  = new Point[10]
Which of the statements is most accurate?
p contains a reference to an array of size 10 and each array element can store a reference to a Point object.

Consider the concrete classes A and B and a method mA partially defined as below :

public class A {
	public mA(B b) { }
}

What is passed as parameter when calling the method mA ?
A reference to an object of type B

Person sally = new Person()
sally nu e o persoana, e o referinta la un obiect de tip Person(), ar fi un numar (hexadecimal care arata unde e stocata persoana in memorie) (un middleman care stie unde este localizat obiectul in memorie)