This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
laboratoare:tutorial-doubledispatch [2014/10/27 16:19] Daniel Ciocirlan [Double Dispatch] |
laboratoare:tutorial-doubledispatch [2014/11/03 10:53] (current) Daniel Ciocirlan |
||
---|---|---|---|
Line 61: | Line 61: | ||
===Double Dispatch=== | ===Double Dispatch=== | ||
- | Să ne uităm încă o dată la soluția precedentă. Observăm că obiectele ''A'' "acționează" asupra obiectelor ''B'', fără ca obiectele ''B'' să aibă nicio "implicare". Obiectele ''B'' sunt doar pasate ca parametri la metodele obiectelor ''A'' iar fiecare obiect ''A'' procesează, în mod polimorfic (**TODO link**), parametrul după implementarea proprie: | + | Să ne uităm încă o dată la soluția precedentă. Observăm că obiectele ''A'' "acționează" asupra obiectelor ''B'', fără ca obiectele ''B'' să aibă nicio "implicare". Obiectele ''B'' sunt doar pasate ca parametri la metodele obiectelor ''A'' iar fiecare obiect ''A'' procesează, în mod [[http://en.wikipedia.org/wiki/Polymorphism_(computer_science)#Subtyping|polimorfic]], parametrul după implementarea proprie: |
<code java> | <code java> | ||
Line 76: | Line 76: | ||
void accept(A a) { | void accept(A a) { | ||
a.interactWith(this); | a.interactWith(this); | ||
- | } | ||
- | |||
- | @Override | ||
- | public String toString() { | ||
- | return "B"; | ||
} | } | ||
} | } | ||
Line 87: | Line 82: | ||
void accept(A a) { | void accept(A a) { | ||
a.interactWith(this); | a.interactWith(this); | ||
- | } | ||
- | |||
- | public String toString() { | ||
- | return "B1"; | ||
} | } | ||
} | } | ||
Line 97: | Line 88: | ||
void accept(A a) { | void accept(A a) { | ||
a.interactWith(this); | a.interactWith(this); | ||
- | } | ||
- | |||
- | @Override | ||
- | public String toString() { | ||
- | return "B2"; | ||
} | } | ||
} | } | ||
Line 114: | Line 100: | ||
</code> | </code> | ||
- | **Întrebarea 1:** Ar avea, oare, același efect? De ce? Încercați! | + | **Întrebarea 1:** Ar avea, oare, același efect ca mai devreme? De ce? Încercați! |
Schimbarea mai mare intervine la clasele ''A''. Să spargem implementarea ''interactWith(B b)'', mutând codul din fiecare bloc ''instanceof'' în metode separate, ca în exemplul următor: | Schimbarea mai mare intervine la clasele ''A''. Să spargem implementarea ''interactWith(B b)'', mutând codul din fiecare bloc ''instanceof'' în metode separate, ca în exemplul următor: | ||
Line 147: | Line 133: | ||
* nu mai facem **absolut niciun test de tip concret** pentru obiectele care interacționează; un mare beneficiu din punctul de vedere al extensibilității | * nu mai facem **absolut niciun test de tip concret** pentru obiectele care interacționează; un mare beneficiu din punctul de vedere al extensibilității | ||
- | De ce se numește acest mecanism double dispatch? //Dispatch// este termenul folosit atunci când gândim ca mașina virtuală Java și ne referim la metoda //concretă// care se apelează la un moment dat. //Double// pentru că interacțiunea observăm că funcționează în ambele sensuri: ''B''-urile cheamă metodela proprie, concretă de ''accept'', care apelează metoda concretă de interacțiune din clasa ''A''. | + | De ce se numește acest mecanism double dispatch? //Dispatch// este termenul folosit atunci când gândim ca mașina virtuală Java și ne referim la metoda //concretă// care se apelează la un moment dat. //Double// pentru că interacțiunea observăm că funcționează în ambele sensuri: ''B''-urile cheamă metoda proprie, concretă de ''accept'', care apelează metoda concretă ''interactWith'' din clasa ''A''. |