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 [2018/10/27 02:17] Cristi Nica |
laboratoare:visitor [2019/11/10 18:05] Adriana Draghici [Exerciţii] |
||
---|---|---|---|
Line 79: | 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 150: | 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 165: | 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 433: | 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-Manager 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 //Manager//, rulați și explicați rezultatul execuției. | + | * implementați structura de clase din diagrama din README |
- | - **(5p)** Obiectele Employee-Manager pot fi reprezentate printr-o structură arborescentă, ce are ca rădăcină un Manager (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. | + | * Pentru simplitatea testării scheletul oferă clasa ''Test'' care oferă bucățile de text pe care să le prelucrați. |
- | * fiecare //Manager// 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) | + | * dacă folosiți IntelliJ creați proiect din scheletul de laborator: File -> New Project -> select Java -> select the skel folder |
- | * implementați un //TreeVisitor// care pentru: | + | * Î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. |
- | * //Employee// - aplică operația primită | + | |
- | * //Manager// - parcurge subordonații și apoi aplică operația primită pe Manager | + | |
- | * implementați un visitor (numit //MostHardworkingEmployeeFinder//) care compară numărul mediu de ore suplimentare pentru angajați cu cel pentru șefi. | + | ** Task 2 ** - Utilizare API implementat folosind Visitor [2p] |
- | - **(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. | + | - Găsiți folosind java.nio toate fișierele cu extensia ".class" sau ".java" dintr-un director. |
- | * modificați clasele existente deja, pentru a lua în considerare și obiectele 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 |
- | * testați operațiile de la exercițiile anterioare pe o colecție care conține și obiecte Intern | + | |
- | * :!: 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: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]] | ||