Programare Orientată pe Obiecte

Differences

This shows you the differences between two versions of the page.

--- laboratoare:tutorial-doubledispatch [2014/10/27 15:06]
Daniel Ciocirlan [O posibilă soluție]
+++ laboratoare:tutorial-doubledispatch [2014/11/03 10:53] (current)
Daniel Ciocirlan
@@ Line 37: / Line 37: @@
 Să răspundem pe rând:
-  * Dacă adăugăm o nouă clasă în ierarhia ''A'', atunci ea trebuie să suprascrie metoda ''interactsWith'', în același stil care tratează tipul efectiv al parametrului. Nu ar fi prea urât. Poate că ar fi, dacă avem multe tipuri ''B''.
+  * Dacă adăugăm o nouă clasă în ierarhia ''A'', atunci ea trebuie să suprascrie metoda ''interactWith'', în același stil care tratează tipul efectiv al parametrului. Nu ar fi prea urât. Poate că ar fi, dacă avem multe tipuri ''B''.
-  * Dacă adăugăm o nouă clasă în ierarhia ''B'' (fie ea ''B3''), atunci trebuie ca fiecare clasă din ierarhia ''A'' să ia în calcul și noua variantă. Trebuie modificate //toate// metodele ''interactsWith'', din //toată// ierarhia ''A'', cu un nou ''instanceof''. **Destul de urât.** Ce ne facem dacă avem 100 de clase ''A''?
+  * Dacă adăugăm o nouă clasă în ierarhia ''B'' (fie ea ''B3''), atunci trebuie ca fiecare clasă din ierarhia ''A'' să ia în calcul și noua variantă. Trebuie modificate //toate// metodele ''interactWith'', din //toată// ierarhia ''A'', cu un nou ''instanceof''. **Destul de urât.** Ce ne facem dacă avem 100 de clase ''A''?
   * Cum arată codul pentru ierarhii mai mari? Cam ca în snippet-ul de mai jos: pentru că mereu descoperim o nouă nevoie de extindere, adăugăm câte un caz nou. //Înmulțit cu numărul de clase ''A''//.
 <code java>
 boolean isPrime(int n) {
+// probably the dumbest way of testing a prime number
+// not even complete (not that it may ever be)
 	if (n == 2)
 		return true;
@@ Line 56: / Line 58: @@
 Evident, ne trebuie ceva mai inteligent.
+===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 [[http://en.wikipedia.org/wiki/Polymorphism_(computer_science)#Subtyping|polimorfic]], parametrul după implementarea proprie:
+<code java>
+A a = new A1();
+B b = new B2();
+a.interactWith(b); // se execută blocul aferent action B2 din clasa A1
+</code>
+Să încercăm să "implicăm" și obiectele ''B''. Dacă ne gândim că obiectele ''A'' interacționează cu obiectele ''B'', ne putem gândi și că obiectele ''B'' "acceptă" interacțiunea. Fie astfel următoarea implementare:
+<code java>
+public class B {
+	void accept(A a) {
+		a.interactWith(this);
+	}
+}
+class B1 extends B {
+	void accept(A a) {
+		a.interactWith(this);
+	}
+}
+class B2 extends B {
+	void accept(A a) {
+		a.interactWith(this);
+	}
+}
+</code>
+Să ne gândim ce s-ar întâmpla dacă am avea următorul snippet (analog cu cel precedent, puțin schimbat):
+<code java>
+A a = new A1();
+B b = new B2();
+b.accept(a);
+</code>
+**Î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:
+<code java>
+void interactWith(B b) {
+// action for B
+}
+void interactWith(B1 b) {
+// action for B1
+}
+void interactWith(B2 b) {
+// action for B2
+}
+</code>
+**Întrebarea 2**: să ne gândim la snippet-ul anterior și să observăm ce se întâmplă la apelul ''b.accept(a)'': ''b'' fiind de fapt un ''B2'', se va apela ''accept'' din clasa ''B2'', care cheamă ''a.interactWith(this)'', ''this'' fiind un ''B2''. Se va apela deci una dintre metodele ''interactWith(B2 b)'', dar din care clasă ''A''? De ce?
+Am ajuns deci să avem:
+  * câte o metodă ''interactWith'' în fiecare clasă ''A'', pentru fiecare tip ''B'' în parte
+  * câte o metodă ''accept(A a)'' în fiecare clasă B
+Ne folosim, astfel, de tipurile concrete ale obiectelor care interacționează, **fără să testăm efectiv tipurile adevărate** în cod. Astfel, gândind în perspectivă, să răspundem la aceleași întrebări:
+  * Dacă adăugăm o nouă clasă în ierarhia ''A'', atunci ea trebuie să suprascrie toate metodele ''interactWith''. Oricum va trebui să implementeze operațiile diferite pentru fiecare ''B'' în parte, iar **modularizarea este un plus**.
+  * Dacă adăugăm o nouă clasă în ierarhia ''B'' (fie ea ''B3''), trebuie să suprascrie metoda ''accept(A a)'', a cărei implementare va fi o singură linie: ''a.interactWith(this)'' => trebuie ca fiecare clasă ''A'' să aibă o nouă metodă ''interactWith(B3 b)''.
+  * Cum arată codul pentru ierarhii mai mari? **Structurat și organizat**:
+    * fiecare clasă ''A'' are propriile implementări de interacțiuni, pe care, la nevoie, le putem modifica imediat, punctual, fără să căutăm în ''instanceof''-uri
+    * 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ă metoda proprie, concretă de ''accept'', care apelează metoda concretă ''interactWith'' din clasa ''A''.

Programare Orientată pe Obiecte

User Tools

Site Tools

Differences

Page Tools