This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
laboratoare:visitor [2017/11/24 18:27] Mihai Burduselu [Resurse] |
laboratoare:visitor [2019/11/10 18:13] Adriana Draghici [Exerciţii] |
||
---|---|---|---|
Line 1: | Line 1: | ||
= More OOP & Visitor pattern = | = More OOP & Visitor pattern = | ||
- | |||
- | * Responsabil: Mihai Burduselu | ||
- | * Data publicării: 08.10.2017 | ||
- | * Data ultimei modificări: 08.10.2017 | ||
== Obiective == | == Obiective == | ||
Line 83: | Line 79: | ||
Suprascrierea se referă la redefinirea metodelor existente în clasa părinte de către clasa copil în vederea specializării acestora. Metodele din clasa parinte nu sunt modificate. Putem suprascrie doar metodele vizibile pe lanțul de moștenire (public, protected). O metodă din clasa copil suprascrie metoda din clasa părinte dacă are același tip de return și aceeași semnatură (nume și parametri). | Suprascrierea se referă la redefinirea metodelor existente în clasa părinte de către clasa copil în vederea specializării acestora. Metodele din clasa parinte nu sunt modificate. Putem suprascrie doar metodele vizibile pe lanțul de moștenire (public, protected). O metodă din clasa copil suprascrie metoda din clasa părinte dacă are același tip de return și aceeași semnatură (nume și parametri). | ||
- | Spre deosebire de supraîncărcare care face acest lucru la compilare, în cazul suprascrierii se determină ce metodă va fi apelată, în mod dinamic, **la runtime**. Explicația este că decizia se face pe baza__ tipului obiectului__ care apelează metoda, deci a instanței (cunoscută la runtime). Din acest motiv, suprascrierea este cunoscută și ca polimorfism dinamic (''Runtime polymorphism''). Polimorfismul reprezintă abilitatea unei clase să se comporte ca o altă clasă de pe lanțul de moștenire, și de aceea conceptul de suprascriere a metodelor este foarte strâns legat. Supraîncărcarea, fiind la compile-time, nu are legătură cu acest polimorfism dinamic. | + | Spre deosebire de supraîncărcare care face acest lucru la compilare, în cazul suprascrierii se determină ce metodă va fi apelată, în mod dinamic, **la runtime**. Explicația este că decizia se face pe baza__ tipului obiectului__ care apelează metoda, deci a instanței (cunoscută la runtime). Din acest motiv, suprascrierea este cunoscută și ca polimorfism dinamic (''Runtime polymorphism''). **Polimorfismul reprezintă abilitatea unei clase să se comporte ca o altă clasă de pe lanțul de moștenire, și de aceea conceptul de suprascriere a metodelor este foarte strâns legat. Supraîncărcarea, fiind la compile-time, nu are legătură cu acest polimorfism dinamic.** |
<note important> La apelarea unei metode suprascrise, Java se uită la tipul intern al obiectului pentru care este apelată metoda, NU la referință. Astfel dacă referința are tipul clasei părinte, dar tipul este al clasei copil, JVM va apela metoda din clasa copil. </note> | <note important> La apelarea unei metode suprascrise, Java se uită la tipul intern al obiectului pentru care este apelată metoda, NU la referință. Astfel dacă referința are tipul clasei părinte, dar tipul este al clasei copil, JVM va apela metoda din clasa copil. </note> | ||
Line 154: | Line 150: | ||
</note> | </note> | ||
+ | === super === | ||
- | == Cuvântul cheie super și overriding == | + | În laboratorul [[laboratoare:agregare-mostenire#cuvantul-cheie-super-intrebuintari|]] am folosit cuvântul cheie **super** pentru a invoca un anumit constructor din clasa părinte dar și pentru a apela în mod explicit metoda din clasa părinte în cazul metodelor suprascrise. |
- | + | ||
- | În laboratoarele trecute am folosit cuvântul cheie //super// pentru a invoca un anumit constructor din clasa părinte. | + | |
- | + | ||
- | O alta utilizare a lui //super// este de a apela in mod explicit metoda din clasa părinte în cazul metodelor suprascrise. | + | |
Rescriem metoda ''purr()'' din clasa ''GrumpyCat'' astfel: | Rescriem metoda ''purr()'' din clasa ''GrumpyCat'' astfel: | ||
Line 169: | Line 162: | ||
} | } | ||
</code> | </code> | ||
- | La apelul metodei pe o instanță a clasei'' GrumpyCat'' output-ul va fi: | + | La apelul metodei pe o instanță a clasei ''GrumpyCat'' output-ul va fi: |
<code> | <code> | ||
purrrr | purrrr | ||
Line 224: | Line 217: | ||
==== Before ==== | ==== Before ==== | ||
- | Fie ierarhia de mai jos, ce defineşte un angajat (//Employee//) şi un şef (//Boss//), văzut, de asemenea, ca un angajat: | + | Fie ierarhia de mai jos, ce defineşte un angajat (//Employee//) şi un şef (//Manager//), văzut, de asemenea, ca un angajat: |
<code java Test.java> | <code java Test.java> | ||
Line 241: | Line 234: | ||
} | } | ||
} | } | ||
- | class Boss extends Employee { | + | class Manager extends Employee { |
float bonus; | float bonus; | ||
- | public Boss(String name, float salary) { | + | public Manager(String name, float salary) { |
super(name, salary); | super(name, salary); | ||
bonus = 0; | bonus = 0; | ||
Line 256: | Line 249: | ||
public class Test { | public class Test { | ||
public static void main(String[] args) { | public static void main(String[] args) { | ||
- | Boss boss; | + | Manager manager; |
List<Employee> employees = new LinkedList<Employee>(); | List<Employee> employees = new LinkedList<Employee>(); | ||
employees.add(new Employee("Alice", 20)); | employees.add(new Employee("Alice", 20)); | ||
- | employees.add(boss = new Boss("Bob", 1000)); | + | employees.add(manager= new Manager("Bob", 1000)); |
- | boss.setBonus(100); | + | manager.setBonus(100); |
} | } | ||
} | } | ||
Line 278: | Line 271: | ||
} | } | ||
} | } | ||
- | class Boss extends Employee { | + | class Manager extends Employee { |
... | ... | ||
public float getTotalRevenue() { | public float getTotalRevenue() { | ||
Line 287: | Line 280: | ||
Acum ne interesează să calculăm //procentul mediu// pe care îl reprezintă bonusul din venitul şefilor, luându-se în considerare doar bonusurile pozitive. Avem două posibilităţi: | Acum ne interesează să calculăm //procentul mediu// pe care îl reprezintă bonusul din venitul şefilor, luându-se în considerare doar bonusurile pozitive. Avem două posibilităţi: | ||
- | * Definim câte o metodă, //getBonusPercentage()//, care în //Employee// întoarce mereu 0, iar în //Boss// raportul real. **Dezavantajul** constă în adăugarea în interfeţe a unor funcţii prea specializate, de detalii ce ţin doar de unele implementări ale acestora. | + | * Definim câte o metodă, //getBonusPercentage()//, care în //Employee// întoarce mereu 0, iar în //Manager// raportul real. **Dezavantajul** constă în adăugarea în interfeţe a unor funcţii prea specializate, de detalii ce ţin doar de unele implementări ale acestora. |
* Parcurgem lista de angajaţi, //testăm//, la fiecare pas, tipul angajatului, folosind ''instanceof'', şi calculăm, doar pentru şefi, raportul solicitat. **Dezavantajul** este tratarea într-o manieră //neuniformă// a structurii noastre, cu evidenţierea particularităţilor fiecărei clase. | * Parcurgem lista de angajaţi, //testăm//, la fiecare pas, tipul angajatului, folosind ''instanceof'', şi calculăm, doar pentru şefi, raportul solicitat. **Dezavantajul** este tratarea într-o manieră //neuniformă// a structurii noastre, cu evidenţierea particularităţilor fiecărei clase. | ||
Line 295: | Line 288: | ||
* în cazul în care nu avem acces la codul claselor, singura modalitate de adăugare de funcţionalitate este extinderea | * în cazul în care nu avem acces la codul claselor, singura modalitate de adăugare de funcţionalitate este extinderea | ||
- | În final, tragem concluzia că este de dorit să **izolăm algoritmii de clasele pe care le prelucrează**. O primă idee se referă la utilizarea //metodelor statice//. Dezavantajul acestora este că nu pot reţine, într-un mod elegant, informaţie de stare din timpul prelucrării. De exemplu, dacă structura noastră ar fi arborescentă (recursivă), în sensul că o instanţă //Boss// ar putea ţine referinţe la alte instanţe //Boss//, ce reprezintă şefii ierarhic inferiori, o funcţie de prelucrare ar trebui să menţină o informaţie parţială de stare (precum suma procentelor calculate până într-un anumit moment) sub forma unor parametri furnizaţi apelului recursiv: | + | În final, tragem concluzia că este de dorit să **izolăm algoritmii de clasele pe care le prelucrează**. O primă idee se referă la utilizarea //metodelor statice//. Dezavantajul acestora este că nu pot reţine, într-un mod elegant, informaţie de stare din timpul prelucrării. De exemplu, dacă structura noastră ar fi arborescentă (recursivă), în sensul că o instanţă //Manager// ar putea ţine referinţe la alte instanţe //Manager//, ce reprezintă şefii ierarhic inferiori, o funcţie de prelucrare ar trebui să menţină o informaţie parţială de stare (precum suma procentelor calculate până într-un anumit moment) sub forma unor parametri furnizaţi apelului recursiv: |
<code java> | <code java> | ||
- | class Boss extends Employee { | + | class Manager extends Employee { |
... | ... | ||
public float getPercentage(float sum, int n) { | public float getPercentage(float sum, int n) { | ||
float f = bonus / getTotalRevenue(); | float f = bonus / getTotalRevenue(); | ||
if (f > 0) | if (f > 0) | ||
- | return inferiorBoss.getPercentage(sum + f, n + 1); // trimite mai departe cererea catre nivelul inferior | + | return inferiorManager.getPercentage(sum + f, n + 1); // trimite mai departe cererea catre nivelul inferior |
- | return inferiorBoss.getPercentage(sum, n); | + | return inferiorManager.getPercentage(sum, n); |
} | } | ||
} | } | ||
Line 313: | Line 306: | ||
==== After ==== | ==== After ==== | ||
- | Conform observațiilor precedente, structura programului Employee-Boss devine: | + | Conform observațiilor precedente, structura programului Employee-Manager devine: |
<code java Test.java> | <code java Test.java> | ||
interface Visitor { | interface Visitor { | ||
- | public void visit(Employee e); | + | public void visit(Employee employee); |
- | public void visit(Boss b); | + | public void visit(Manager manager); |
} | } | ||
interface Visitable { | interface Visitable { | ||
Line 329: | Line 322: | ||
} | } | ||
} | } | ||
- | class Boss extends Employee { | + | class Manager extends Employee { |
... | ... | ||
public void accept(Visitor v) { | public void accept(Visitor v) { | ||
Line 348: | Line 341: | ||
<code java RevenueVisitor.java> | <code java RevenueVisitor.java> | ||
public class RevenueVisitor implements Visitor { | public class RevenueVisitor implements Visitor { | ||
- | public void visit(Employee e) { | + | public void visit(Employee employee) { |
- | System.out.println(e.getName() + " " + e.getSalary()); | + | System.out.println(employee.getName() + " " + employee.getSalary()); |
} | } | ||
- | public void visit(Boss b) { | + | public void visit(Manager manager) { |
- | System.out.println(b.getName() + " " + (b.getSalary() + b.getBonus())); | + | System.out.println(manager.getName() + " " + (manager.getSalary() + manager.getBonus())); |
} | } | ||
} | } | ||
Line 365: | Line 358: | ||
În exemplul de mai sus, putem identifica : | În exemplul de mai sus, putem identifica : | ||
* Element - Visitable | * Element - Visitable | ||
- | * ConcreteElement - Employee, Boss | + | * ConcreteElement - Employee, Manager |
=== Double-dispatch === | === Double-dispatch === | ||
- | Mecanismul din spatele pattern-ului Visitor poartă numele de **double-dispatch**. Acesta este un concept raspândit, şi se referă la faptul că metoda apelată este determinată la //runtime// de doi factori. În exemplul Employee-Boss, efectul vizitarii, solicitate prin apelul ''e.accept(v)'', depinde de: | + | Mecanismul din spatele pattern-ului Visitor poartă numele de **double-dispatch**. Acesta este un concept raspândit, şi se referă la faptul că metoda apelată este determinată la //runtime// de doi factori. În exemplul Employee-Manager, efectul vizitarii, solicitate prin apelul ''e.accept(v)'', depinde de: |
- | * tipul elementului vizitat, ''e'' (//Employee// sau //Boss//), pe care se invocă metoda | + | * tipul elementului vizitat, ''e'' (//Employee// sau //Manager//), pe care se invocă metoda |
* tipul vizitatorului, ''v'' (//RevenueVisitor//), care conţine implementările metodelor //visit// | * tipul vizitatorului, ''v'' (//RevenueVisitor//), care conţine implementările metodelor //visit// | ||
Line 437: | Line 430: | ||
| | ||
== Exerciţii == | == Exerciţii == | ||
- | - **(1p)** Fișierul //Examples// din scheletul de laborator conține exemple de overriding și overloading. Modificați codul din el astfel încât să poată fi compilat. Observați output-ul. | + | |
- | - Cum vă explicați output-ul ''Constructor A, s = hi this = B@5ad557c2'' ? Revedeți [[.:visitor#overriding|nota din sectiunea Overriding]] pentru o explicație. | + | ** Task 1 ** [8p] |
- | - Ce va afișa apelul ''c.f()''? (gândiți-vă voi fără să rulați) | + | |
- | - Care 2 linii le afișează ''new Examples().test(a2);'' și de ce? | + | Dorim să prelucrăm bucăți de text pe care să le convertim în diferite formate, momentan dokuwiki și markdown. Pentru un design decuplat între obiectele prelucrate și tipurile de formate dorite, implementați conversia folosind patternul Visitor. |
- | - **(1p)** Scheletul de laborator conține implementarea folosind pattern-ul Visitor a scenariului Employee-Boss descris [[.:visitor#scenariu-visitor| mai sus]]. Spre deosebire de exemplele din laborator, clasa Employee conține și câmpul extraHours, relevant pentru exercițiul 3. | + | |
- | * a) Rulați codul și observați comportamentul și interacțiunea dintre obiectele vizitate și obiectul de tip Visitor. | + | * Fișierul **[[https://github.com/oop-pub/laboratoare/tree/master/visitor/skel|README]]** din scheletul de cod cuprinde informațiile necesare designului dorit. |
- | * b) Nu mai suprascrieți metoda ''accept'' din //Boss//, rulați și explicați rezultatul execuției. | + | * implementați structura de clase din diagrama din README |
- | - **(5p)** Obiectele Employee-Boss pot fi reprezentate printr-o structură arborescentă, ce are ca rădăcină un Boss (ceo-ul). Creați un Visitor care să permită parcurgerea ierarhiei și efectuarea unei acțiuni pe fiecare nod. Acea acțiune este practic o operație, implementată într-o altă clasă de tip Visitor, deci TreeVisitor-ul va primi un obiect de tip Visitor pe care să îl aplice pe nodurile parcurse. | + | * implementați TODO-urile din scheletul de cod |
- | * fiecare //Boss// va ţine referinţe către angajaţii aflaţi sub răspunderea lui directă (ce pot fi alţi șefi la rândul lor, sau salariaţi obişnuiţi) | + | * Pentru simplitatea testării scheletul oferă clasa ''Test'' care oferă bucățile de text pe care să le prelucrați. |
- | * implementați un //TreeVisitor// care pentru: | + | * dacă folosiți IntelliJ creați proiect din scheletul de laborator: File -> New Project -> select Java -> select the skel folder |
- | * //Employee// - aplică operația primită | + | * În implementare va trebui sa folositi clasa [[https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/StringBuilder.html|StringBuilder]]. Aceasta este o clasă mutabilă (//mutable//), spre deosebire de String, care e imutabilă (//immutable//). Vă recomandăm [[https://www.geeksforgeeks.org/string-vs-stringbuilder-vs-stringbuffer-in-java/|acest link]] pentru un exemplu si explicații despre diferențele dintre ele. |
- | * //Boss// - parcurge subordonații și apoi aplică operația primită pe Boss | + | |
- | * implementați un visitor (numit //MostHardworkingEmployeeFinder//) care compară numărul mediu de ore suplimentare pentru angajați cu cel pentru șefi. | + | |
- | - **(3p)** Adăugați încă un tip de obiect vizitabil - //Intern//. Acesta nu are salariu și extra hours, doar nume și durata (în luni) a internship-ului. | + | ** Task 2 ** - Utilizare API implementat folosind Visitor [2p] |
- | * modificați clasele existente deja, pentru a lua în considerare și obiectele Intern | + | - Găsiți folosind java.nio toate fișierele cu extensia ".class" sau ".java" dintr-un director. |
- | * testați operațiile de la exercițiile anterioare pe o colecție care conține și obiecte Intern | + | * implementați un [[https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/nio/file/FileVisitor.html | FileVisitor]], extinzând [[https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/nio/file/SimpleFileVisitor.html | SimpleFileVisitor]] în care suprascrieți metoda de vizitare a fișierelor |
- | * :!: Observați modificările pe care le-ați efectuat pentru a adăuga o nouă operație (ex. 2) și pe cele pentru a adăuga un nou tip de obiect în colecție. Ca să merite să aplicăm pattern-ul Visitor, ce situație ar trebui să fie evitată? | + | |
- | - **(bonus - 2p)** Găsiți folosind java.nio toate fișierele cu extensia ".class" dintr-un director. | + | |
- | * implementați un [[http://docs.oracle.com/javase/8/docs/api/index.html?java/nio/file/FileVisitor.html | FileVisitor]], extinzând [[http://docs.oracle.com/javase/8/docs/api/java/nio/file/SimpleFileVisitor.html | SimpleFileVisitor]] în care suprascrieți metoda de vizitare a fișierelor | + | |
* un exemplu similar găsiți în [[http://docs.oracle.com/javase/tutorial/essential/io/walk.html | acest tutorial]] | * un exemplu similar găsiți în [[http://docs.oracle.com/javase/tutorial/essential/io/walk.html | acest tutorial]] | ||
- | * Clasele din API-ul //nio// folosite pentru acest exercițiu sunt disponibile începând cu jdk7. | ||
== Resurse == | == Resurse == | ||
- | * {{.:visitor:visitor-skel.zip| Schelet cod}} | + | |
- | * <html><a class="media mediafile mf_pdf" href="/poo/laboratoare/visitor?do=export_pdf">PDF laborator</a></html> | + | * {{{ :laboratoare:visitor:lab-visitor-skel.zip |Schelet de cod}} |
- | * **{{:laboratoare:visitor: visitor-sol.zip | Soluție}}** | + | * [[laboratoare:old-exercises|Exerciții din alți ani]] |
== Referințe == | == Referințe == | ||
- Kathy Sierra, Bert Bates. //SCJP Sun Certified Programmer for Java™ 6 - Study Guide//. Chapter 2 - Object Orientation ([[http://firozstar.tripod.com/_darksiderg.pdf|available online]]) - moștenire, polimorfism, overriding, overloading + exemple de întrebări | - Kathy Sierra, Bert Bates. //SCJP Sun Certified Programmer for Java™ 6 - Study Guide//. Chapter 2 - Object Orientation ([[http://firozstar.tripod.com/_darksiderg.pdf|available online]]) - moștenire, polimorfism, overriding, overloading + exemple de întrebări | ||
- | - Vlissides, John, et al. //Design patterns: Elements of reusable object-oriented software//. Addison-Wesley (1995) | + | - Vlissides, John, et al. //Design patterns: Elements of reusable object-oriented software//. Addison-Wesley (1995) ([[https://sophia.javeriana.edu.co/~cbustaca/docencia/DSBP-2018-01/recursos/Erich%20Gamma,%20Richard%20Helm,%20Ralph%20Johnson,%20John%20M.%20Vlissides-Design%20Patterns_%20Elements%20of%20Reusable%20Object-Oriented%20Software%20%20-Addison-Wesley%20Professional%20(1994).pdf|available online]]) |
- [[http://en.wikipedia.org/wiki/Software_design_pattern | Clasificarea design pattern-urilor]] | - [[http://en.wikipedia.org/wiki/Software_design_pattern | Clasificarea design pattern-urilor]] | ||
- [[laboratoare:tutorial-doubledispatch| Tutorial double-dispatch]] | - [[laboratoare:tutorial-doubledispatch| Tutorial double-dispatch]] | ||