Differences
This shows you the differences between two versions of the page.
|
poo-ca-cd:laboratoare:design-patterns-part-one [2025/11/24 10:02] florian_luis.micu [Soluția] |
poo-ca-cd:laboratoare:design-patterns-part-one [2025/11/24 11:05] (current) florian_luis.micu [Single Dispatch] |
||
|---|---|---|---|
| Line 226: | Line 226: | ||
| * thread-safe implicit | * thread-safe implicit | ||
| - | ===== De ce folosim Singleton?===== | + | ===== Avantaje ===== |
| ^ Avantaj ^ De ce e util ^ | ^ Avantaj ^ De ce e util ^ | ||
| Line 364: | Line 364: | ||
| **Factory Method** evită această problemă prin **mutarea instanțierii în subclase**. | **Factory Method** evită această problemă prin **mutarea instanțierii în subclase**. | ||
| - | ====Structura patternului==== | + | ====Structura pattern-ului==== |
| Structura se bazează pe 3 elemente: | Structura se bazează pe 3 elemente: | ||
| Line 443: | Line 443: | ||
| </code> | </code> | ||
| + | ====Avantaje importante==== | ||
| - | <note tip> | + | Factory Method oferă flexibilitate: fiecare subclasă de fabrică **decide ce obiecte creează**, fără ca restul aplicației să fie afectat. Clientul folosește doar metoda ''create()'' și nu trebuie să știe //cum// sau //ce tip// concret este instanțiat. |
| - | **Factory Method** nu creează o familie întreagă de obiecte, ci **un singur tip de obiect per creator**. Este util atunci când obiectele sunt legate de **responsabilitatea unui singur creator**. | + | |
| - | </note> | + | Acest pattern devine valoros atunci când sistemul **trebuie extins cu noi tipuri de produse**. Adăugarea unui nou tip implică doar **crearea unei noi fabrici** sau a unei **noi implementări a metodei**, fără modificarea codului existent, ceea ce îmbunătățește **izolarea**, **testarea** și **mentenanța**. |
| ===== Abstract Factory ===== | ===== Abstract Factory ===== | ||
| Line 463: | Line 464: | ||
| **Abstract Factory** garantează **consistența interfeței** și separă clar logica aplicației de logica de randare pentru exemplul dat. | **Abstract Factory** garantează **consistența interfeței** și separă clar logica aplicației de logica de randare pentru exemplul dat. | ||
| - | ==== Structura patternului ==== | + | ==== Structura pattern-ului ==== |
| Patternul are 4 componente principale: | Patternul are 4 componente principale: | ||
| Line 635: | Line 636: | ||
| <code java> | <code java> | ||
| - | package visitor_second_iteration; | ||
| - | |||
| interface Node { | interface Node { | ||
| void show(); | void show(); | ||
| Line 684: | Line 683: | ||
| * Overloading nu respectă tipul obiectului la runtime. | * Overloading nu respectă tipul obiectului la runtime. | ||
| * Aceasta nu rezolvă complet problema și nu scalează dacă avem o colecție heterogenă de noduri. | * Aceasta nu rezolvă complet problema și nu scalează dacă avem o colecție heterogenă de noduri. | ||
| + | |||
| + | <note important> | ||
| + | Polimorfismul dinamic **nu** ar avea problema de mai devreme. De exemplu, aceste apeluri sunt rezolvate corect la runtime:<code java> | ||
| + | city.show(); // va apela metoda suprascrisă din City | ||
| + | industry.show(); // va apela metoda suprascrisă din Industry | ||
| + | </code> | ||
| + | |||
| + | Însă această soluție permite **un singur comportament de afișare** per clasă. Dacă vrem să afișăm același obiect în mai multe formate (TEXT, JSON, XML), nu putem suprascrie ''show()'' de trei ori. Ar trebui să delegăm afișarea către clase externe (''ExporterText'', ''ExporterJson'', ''ExporterXml''), iar dacă folosim overloading pentru acestea, revenim la aceeași problemă: **overloading-ul se decide la compile-time**, ignorând tipul real al obiectului. | ||
| + | </note> | ||
| **Concluzie:** | **Concluzie:** | ||
| Line 725: | Line 733: | ||
| <note tip> | <note tip> | ||
| - | Aceasta este situația clasică unde single dispatch și overloading nu sunt suficiente. Avem nevoie de double dispatch. | + | Aceasta este situația clasică unde **single dispatch și overloading nu sunt suficiente**. Avem nevoie de **double dispatch**. |
| </note> | </note> | ||
| Line 797: | Line 805: | ||
| <code java> | <code java> | ||
| class NodeVisitor implements Visitor { | class NodeVisitor implements Visitor { | ||
| - | public void visit(City city) { System.out.println("Process City"); } | + | public void visit(City city) { System.out.println("Export City"); } |
| - | public void visit(Industry industry) { System.out.println("Process Industry"); } | + | public void visit(Industry industry) { System.out.println("Export Industry"); } |
| - | public void visit(SightSeeing sightSeeing) { System.out.println("Process SightSeeing"); } | + | public void visit(SightSeeing sightSeeing) { System.out.println("Export SightSeeing"); } |
| } | } | ||
| </code> | </code> | ||
| Line 834: | Line 842: | ||
| - Operațiile se adaugă mai des decât clasele obiectelor. | - Operațiile se adaugă mai des decât clasele obiectelor. | ||
| - Dorim să separăm algoritmii de structura de date, păstrând clasele vizitabile simple. | - Dorim să separăm algoritmii de structura de date, păstrând clasele vizitabile simple. | ||
| + | |||
| + | **TL;DR:** Folosim Visitor când vrem să avem **mai mulți algoritmi** (ex. ExporterPDF, ExporterXML, ExporterJSON) pentru **mai multe tipuri de entități** (ex. SeightSeeing, Industry, City). | ||
| </note> | </note> | ||
| Line 890: | Line 900: | ||
| {{:poo-ca-cd:laboratoare:design-patterns-part-one:proxy.png?nolink&500|}} | {{:poo-ca-cd:laboratoare:design-patterns-part-one:proxy.png?nolink&500|}} | ||
| - | =====Exemplu concret===== | + | =====Exemplu complet===== |
| **1. Interfața Subject** | **1. Interfața Subject** | ||
| Line 1034: | Line 1044: | ||
| * [[https://refactoring.guru/design-patterns/proxy|Proxy - Refactoring Guru]] | * [[https://refactoring.guru/design-patterns/proxy|Proxy - Refactoring Guru]] | ||
| * [[:poo-ca-cd:laboratoare:tutorial-doubledispatch]] | * [[:poo-ca-cd:laboratoare:tutorial-doubledispatch]] | ||
| + | * //"Design Patterns: Elements of Reusable Object-Oriented Software"// (Gang of Four) - Erich Gamma | ||
