Differences
This shows you the differences between two versions of the page.
|
poo:breviare:breviar-12 [2018/12/10 22:15] carmen.odubasteanu [Descriere] |
poo:breviare:breviar-12 [2018/12/11 17:02] (current) carmen.odubasteanu |
||
|---|---|---|---|
| Line 87: | Line 87: | ||
| Uneori suntem nevoiti sa cream obiecte in functiile de preferinta unui utilizator in cadrul unei aplicatii sau dupa alta necesitati. | Uneori suntem nevoiti sa cream obiecte in functiile de preferinta unui utilizator in cadrul unei aplicatii sau dupa alta necesitati. | ||
| - | De aceea, folosim pattern-ul Factory, prin care alcatuim o familie de clase care sunt inrudite intre ele, prin faptul ca ele mostenesc aceeasi clasa abstracta sau ca implementeaza aceeasi interfata. Astfel, prin exemplul de cod ilustrat mai jos, daca utilizatorul doreste sa afle informatii despre un tip de pizza, el va scrie la tastatura numele acelui tip de pizza si, daca tipul respectiv exista, el va primi informatii despre acel tip de pizza. | + | De aceea, folosim pattern-ul Factory, prin care alcatuim o familie de clase care sunt inrudite intre ele, prin faptul ca ele mostenesc aceeasi clasa abstracta sau ca implementeaza aceeasi interfata. |
| + | {{ :poo:breviare:factory_pattern_uml_diagram.jpg | Diagrama exemplu Factory}} | ||
| + | |||
| + | Astfel, prin exemplul de cod ilustrat mai jos, daca utilizatorul doreste sa afle informatii despre un tip de pizza, el va scrie la tastatura numele acelui tip de pizza si, daca tipul respectiv exista, el va primi informatii despre acel tip de pizza. | ||
| - | // insertie imagine factory_pattern_uml_diagram.jpg | ||
| interface IPizza { | interface IPizza { | ||
| Line 110: | Line 112: | ||
| class PizzaQuattroStagioni extends Pizza { | class PizzaQuattroStagioni extends Pizza { | ||
| public void showStuff() { | public void showStuff() { | ||
| - | System.out.println("Sos tomat, branza Mozzarella, sunca, pepperoni, ciuperci, | + | System.out.println("Sos tomat, branza Mozzarella, sunca, pepperoni, |
| - | ardei. "); | + | ciuperci, ardei. "); |
| } | } | ||
| } | } | ||
| Line 140: | Line 142: | ||
| - | Un clasa de tip Factory poate fi utilizata in mai multe locuri in cadrul unui proiect si pentru a economisi resurse putem folosi pattern-ul Singleton, existand o singura instanta a clasei Factory. | + | O clasa de tip Factory poate fi utilizata in mai multe locuri in cadrul unui proiect si pentru a economisi resurse putem folosi pattern-ul Singleton, existand o singura instanta a clasei Factory. |
| ===== Behavioral Patterns ===== | ===== Behavioral Patterns ===== | ||
| Line 150: | Line 152: | ||
| Acest design pattern stabileste o relatie one to many intre obiecte. Mai exact, avem un obiect pe care il numim subiect, caruia ii este asociat o colectie, o lista de observatori, care sunt obiecte dependente de subiect, notificate in mod automat de catre subiect, cand in cadrul subiectului are loc o actiune sau o modificare a starii subiectului. | Acest design pattern stabileste o relatie one to many intre obiecte. Mai exact, avem un obiect pe care il numim subiect, caruia ii este asociat o colectie, o lista de observatori, care sunt obiecte dependente de subiect, notificate in mod automat de catre subiect, cand in cadrul subiectului are loc o actiune sau o modificare a starii subiectului. | ||
| - | // insert image observer.jpg | ||
| + | {{ :poo:breviare:observer.jpg?500 | Diagrama Observer}} | ||
| ==== Strategy Pattern ==== | ==== Strategy Pattern ==== | ||
| Line 158: | Line 160: | ||
| === Descriere === | === Descriere === | ||
| - | Strategy reprezinta un design pattern behavioural ce ofera o familie de algoritmi, adica de strategii, incapsulate in clase ce ofera o interfata de folosire (in cazul exemplului de mai jos - intefata Strategy), din care clientii / utilizatorii pot sa aleaga. Acest design pattern este recomandat daca este nevoie de un tip de strategie / algoritm cu mai multe implementari posibile si se doreste sa se aleaga in mod dinamic un algoritm pentru a-l folosi. De exemplu, daca ne dorim sa cautam un element intr-o colectie putem sa vedem mai intai daca este sortata colectia sau nu, ca sa vedem de algoritm de cautare folosim. Daca este colectia sortata, putem aplica algoritmul de cautare binara in colectie, altfel putem sa facem o simpla iterare prin colectie ca sa vedem cautam elementul dorit. | + | Strategy reprezinta un design pattern behavioural ce ofera o familie de algoritmi, adica de strategii, incapsulate in clase ce ofera o interfata de folosire (in cazul exemplului de mai jos - intefata Strategy), din care clientii / utilizatorii pot sa aleaga. Acest design pattern este recomandat daca este nevoie de un tip de strategie / algoritm cu mai multe implementari posibile si se doreste sa se aleaga in mod dinamic un algoritm pentru a-l folosi. De exemplu, daca ne dorim sa cautam un element intr-o colectie putem sa vedem mai intai daca este sortata colectia sau nu, ca sa vedem ce algoritm de cautare folosim. Daca este colectia sortata, putem aplica algoritmul de cautare binara in colectie, altfel putem sa facem o simpla iterare prin colectie ca sa vedem cautam elementul dorit. |
| - | // insert image strategy.png | + | |
| + | {{ :poo:breviare:strategy.png?700 | Diagrama Strategy }} | ||
| ==== Visitor Pattern ==== | ==== Visitor Pattern ==== | ||
| Line 169: | Line 172: | ||
| In cadrul acestui design pattern, avem o interfata Visitor, care reprezinta operatia aplicata, si o interfata / clasa abstracta Visitable (numita in imagine Element), care reprezinta obiectele pe care se aplicatii operatiile din clasele de tip Visitor. In clasele Visitor, vom avea o metoda visit, prin care Visitorul "viziteaza" un obiect tinta, care este reprezentat ca fiind de tip Visitable, o clasa de tip Visitable continand o metoda accept, care accepta "vizita" Visitor-ului asupra sa. | In cadrul acestui design pattern, avem o interfata Visitor, care reprezinta operatia aplicata, si o interfata / clasa abstracta Visitable (numita in imagine Element), care reprezinta obiectele pe care se aplicatii operatiile din clasele de tip Visitor. In clasele Visitor, vom avea o metoda visit, prin care Visitorul "viziteaza" un obiect tinta, care este reprezentat ca fiind de tip Visitable, o clasa de tip Visitable continand o metoda accept, care accepta "vizita" Visitor-ului asupra sa. | ||
| - | // insert image visitor.jpg | + | |
| + | {{ :poo:breviare:visitor.jpg?700 | Diagrama Visitor}} | ||
| Un exemplu de Visitor este implementarea de operatii pentru fisiere precum cat si ls. In cadrul acestui exemplu, vom avea ca Visitori clasele Ls si Cat, iar ca Visitable vom avea clasele Fisier si Folder, care mostenesc o clasa abstracta numita Repository. Vom exemplifica mai jos, pentru o mai buna intelegere: | Un exemplu de Visitor este implementarea de operatii pentru fisiere precum cat si ls. In cadrul acestui exemplu, vom avea ca Visitori clasele Ls si Cat, iar ca Visitable vom avea clasele Fisier si Folder, care mostenesc o clasa abstracta numita Repository. Vom exemplifica mai jos, pentru o mai buna intelegere: | ||
| interface Visitor { | interface Visitor { | ||
| - | void visit (Folder f); | + | void visit (Director f); |
| void visit (Fisier f); | void visit (Fisier f); | ||
| } | } | ||
| - | + | class Ls implements Visitor { | |
| - | class Ls: Visitor { | + | public void visit (Director f) { |
| - | public void visit (Folder f) { | + | |
| System.out.println(f.getName()); | System.out.println(f.getName()); | ||
| for (Repository repo: f.getChildren()) { | for (Repository repo: f.getChildren()) { | ||
| Line 186: | Line 189: | ||
| } | } | ||
| } | } | ||
| - | + | public void visit (Fisier f) { | |
| - | public void visit (File f) { | + | |
| System.out.println("Not a folder"); | System.out.println("Not a folder"); | ||
| /* comanda Ls (in acest exemplu) este specifica doar folderelor, | /* comanda Ls (in acest exemplu) este specifica doar folderelor, | ||
| Line 195: | Line 197: | ||
| } | } | ||
| } | } | ||
| - | + | class Cat implements Visitor { | |
| - | class Cat: Visitor { | + | public void visit (Director f) { |
| - | public void visit (Folder f) { | + | |
| // avertisment ca avem folder, nu fisier | // avertisment ca avem folder, nu fisier | ||
| } | } | ||
| - | + | public void visit (Fisier f) { | |
| - | public void visit (File f) { | + | |
| // citire fisier, folosind numele fisierului | // citire fisier, folosind numele fisierului | ||
| } | } | ||
| } | } | ||
| - | |||
| abstract class Repository { | abstract class Repository { | ||
| private String name; | private String name; | ||
| Line 212: | Line 211: | ||
| return name; | return name; | ||
| } | } | ||
| - | |||
| public abstract void accept (Visitor f); | public abstract void accept (Visitor f); | ||
| } | } | ||
| - | |||
| class Fisier extends Repository { | class Fisier extends Repository { | ||
| public void accept (Visitor f) { | public void accept (Visitor f) { | ||
| Line 223: | Line 220: | ||
| } | } | ||
| } | } | ||
| - | + | class Director extends Repository { | |
| - | class Folder extends Repository { | + | private List<Repository> children = new ArrayList<>(); |
| - | private List<Repository> children = new ArrayList<>(); | + | |
| - | | + | |
| public List<Repository> getChildren() { | public List<Repository> getChildren() { | ||
| return children; | return children; | ||
| } | } | ||
| - | |||
| public void accept (Visitor f) { | public void accept (Visitor f) { | ||
| f.visit(this); | f.visit(this); | ||
| Line 236: | Line 230: | ||
| } | } | ||
| - | |||
| - | {{:poo:breviare:lab12_var_final.pdf|}} | ||
