Differences
This shows you the differences between two versions of the page.
|
poo:breviare:breviar-12 [2018/12/10 22:12] carmen.odubasteanu |
poo:breviare:breviar-12 [2018/12/11 17:02] (current) carmen.odubasteanu |
||
|---|---|---|---|
| Line 22: | Line 22: | ||
| ===== Singleton Pattern ===== | ===== Singleton Pattern ===== | ||
| - | Descriere | + | ==== Descriere ==== |
| Uneori ne dorim sa avem un obiect care sa apara doar o singura data intr-o aplicatie, de exemplu conducatorul unei tari (deoarece nu are sens sa existe mai multi in acelasi context). De aceea folosim Singleton, un mod prin care restrictionam numarul de instantieri a unei clase, ea avand o singura referinta ce va fi folosita in intreg proiectul. Astfel, pentru a asigura restrictionarea, clasa de tip Singleton va avea un constructor privat | Uneori ne dorim sa avem un obiect care sa apara doar o singura data intr-o aplicatie, de exemplu conducatorul unei tari (deoarece nu are sens sa existe mai multi in acelasi context). De aceea folosim Singleton, un mod prin care restrictionam numarul de instantieri a unei clase, ea avand o singura referinta ce va fi folosita in intreg proiectul. Astfel, pentru a asigura restrictionarea, clasa de tip Singleton va avea un constructor privat | ||
| Line 29: | Line 30: | ||
| public class SingletonClass { | public class SingletonClass { | ||
| /* | /* | ||
| - | la inceput, inainte de prima si singura instantiere a clasei SingletonClass | + | la inceput, inainte de prima si singura instantiere a clasei SingletonClass |
| - | va avea valoarea null | + | va avea valoarea null |
| */ | */ | ||
| private static SingletonClass obj = null; | private static SingletonClass obj = null; | ||
| Line 74: | Line 75: | ||
| } | } | ||
| | | ||
| - | Utilizari | + | ==== Utilizari ==== |
| Utilizarile acestui pattern sunt: | Utilizarile acestui pattern sunt: | ||
| Line 83: | Line 84: | ||
| ===== Factory ===== | ===== Factory ===== | ||
| - | Descriere | + | ==== Descriere ==== |
| 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 108: | 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 138: | 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 145: | Line 149: | ||
| ==== Observer Pattern ==== | ==== Observer Pattern ==== | ||
| - | Descriere | + | === Descriere === |
| 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 ==== | ||
| - | 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. | + | |
| - | // insert image strategy.png | + | 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. |
| + | |||
| + | {{ :poo:breviare:strategy.png?700 | Diagrama Strategy }} | ||
| ==== Visitor Pattern ==== | ==== Visitor Pattern ==== | ||
| - | Descriere | + | === Descriere === |
| Acest design pattern ofera posibilitatea de a separa un algoritm de structura de date pe care acesta opereaza, astfel noua ne este usor sa adaugam functii noi care opereaza peste o familie de clase, fara sa modificam structura acestora. Pe scurt, folosim Visitor daca avem tipuri diferite si dorim sa adaugam sau sa schimbam operatii fara sa modificam clasele. | Acest design pattern ofera posibilitatea de a separa un algoritm de structura de date pe care acesta opereaza, astfel noua ne este usor sa adaugam functii noi care opereaza peste o familie de clase, fara sa modificam structura acestora. Pe scurt, folosim Visitor daca avem tipuri diferite si dorim sa adaugam sau sa schimbam operatii fara sa modificam clasele. | ||
| 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()) { | ||
| - | System.out.println("\t" + repo.getName()); // afisam numele unui repo (fisier / folder) | + | System.out.println("\t" + repo.getName()); |
| + | // afisam numele unui repo (fisier / folder) | ||
| } | } | ||
| } | } | ||
| - | + | 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, in acest caz este evidentiat un dezavantaj al Visitor-ului, faptul ca noi trebuie sa implementam metode de care nu avem nevoie in acest caz - se incalca Interface Segregation Principle */ | + | /* comanda Ls (in acest exemplu) este specifica doar folderelor, |
| + | in acest caz este evidentiat un dezavantaj al Visitor-ului, | ||
| + | faptul ca noi trebuie sa implementam metode de care nu avem nevoie | ||
| + | in acest caz - se incalca Interface Segregation Principle */ | ||
| } | } | ||
| } | } | ||
| - | + | 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; // numele unui fisier sau folder (de fapt, calea acestuia) | + | private String name; |
| + | // numele unui fisier sau folder (de fapt, calea acestuia) | ||
| public String getName() { | public String getName() { | ||
| 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) { | ||
| - | f.visit(this); // Visitor-ul "viziteaza" fisierul, adica acesta efectueaza o operatie asupra fisierului | + | f.visit(this); |
| + | // Visitor-ul "viziteaza" fisierul, adica acesta | ||
| + | //efectueaza o operatie asupra fisierului | ||
| } | } | ||
| } | } | ||
| - | + | 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 224: | Line 230: | ||
| } | } | ||
| - | |||
| - | {{:poo:breviare:lab12_var_final.pdf|}} | ||
