Changes between Version 8 and Version 9 of Variante2

Timestamp:

Aug 20, 2006, 8:47:29 PM (18 years ago)

Author:

soujak

Comment:

--

Variante2

@@ -43 +43 @@
  * L'aggiunta di una operazione non deve richiedere nessun
    cambiamento al modello
-[[BR]]''20060819-1310 [SoujaK] [[BR]]
-Le operazioni non devono perrtanto risiedere all'interno del modello, ma all'
-esterno, negli specifici visitor/iterator. Il modello esporra' nella sua
-interfaccia la classica `accept(AbstractVisitor)`. Raggruppare l'interfaccia
-dei visitor permette al modello di essere totalmente indipendente dall'aggiunta
-di nuove operazioni.
-E per quanto riguarda gli iteratori?''
+   [[BR]]20060819-1310 [SoujaK] ''Le operazioni non devono perrtanto risiedere
+   all'interno del modello, ma all'esterno, negli specifici visitor/iterator.
+   Il modello esporra' nella sua interfaccia la classica
+   `accept(AbstractVisitor)`. Raggruppare l'interfaccia dei visitor permette al
+   modello di essere totalmente indipendente dall'aggiunta di nuove
+   operazioni.''
+   [[BR]] 20060819-1617 [SoujaK] [[BR]] ''E per quanto riguarda gli iteratori?''
 
 Le scelte di design devono essere imposte al cliente.
@@ -56 +56 @@
  * Il codice e i pattern non conformi a questa specifica non
    devono fare parte del sistema fornito
-[[BR]]''20060818-1501 [SoujaK] [[BR]]
-Quali pattern creazionali? E' necessario il redesign di questa sezione, oppure
-la vecchia Factory adempie gia' a questo compito? Volendo si potrebbe pensare a
-soluzioni alternative, ma reputo la cosa a bassa priorita'.''
+   [[BR]] 20060818-1501 [SoujaK] ''Quali pattern creazionali? E' necessario il
+   redesign di questa sezione, oppure la vecchia Factory adempie gia' a questo
+   compito? Volendo si potrebbe pensare a soluzioni alternative, ma reputo la
+   cosa a bassa priorita'.''
 
-=== Scelte progettuali ===
+=== Diaro di bordo: dubbi, problemi e conseguenti scelte ===
+
+20060725-1758 [gnappo] [[BR]]
+Le API di manipolazione generiche sono dei getter e setter che agiscono
+sull'intero modello. Per approfondire seguite il
+[http://www.cs.unibo.it/~solmi/teaching/labss_2005-2006/EserciziProgetto2.pdf link].
+Se non bastasse vi rimando all'
+[http://www.cs.unibo.it/~solmi/teaching/labss_2005-2006/esercizi/labss_il_model_iterators.zip esempio]
+del prof. Solmi: prestate attenzione alle classi !LanguageEntity e alle varie
+Abstract* (sono particolarmente chiarificatrici).
 
 20060818-1918 [SoujaK] [[BR]]
@@ -68 +77 @@
 sollevamento di un eccezione).
 
+20060820-1238 [SoujaK] [[BR]]
+Natura del modello: la struttura solitamente pensata come un albero di
+espressioni e' rappresentata grazie a campi interni degli oggetti che compongono
+l'aggregato. Si tratta di `List` o `ArrayList` nel caso di nodi non terminali,
+altrimenti tipi specifici (bool, String, int) a seconda del caso. Il problema
+che sorge e' come riuscire a far attraversare un aggregato cosi' eterogeneo da
+un Visitor o da un Iterator.
+'' Forse potrebbe avere senso fare come e' stato fatto per Variante 1, cioe'
+far diventare i campi interni degli !SchemeValue. ''
+
+20060820-1332 [SoujaK] [[BR]]
+Le API di manipolazione specifica (`getter` e/o `setter`) diventano piu' che mai
+necessari in questa variante, perche' le operazioni sul modello devono essere
+effettuate all'esterno di esso. Affinche' i `Visitor` riescano nel loro intento
+hanno ovviamente bisogno di conoscere l'oggetto che intendono visitare.
+
+20060820-1817 [SoujaK] [[BR]]
+Durante l'implementazione dei Visitor si pone un problema di natura progettuale:
+chi e` responsabile dell'attraversamento della struttura a oggetti?[[BR]]
+La possibilita' di utilizzare un Iterator esterno e` stata discussa da tutta la
+squadra e non verra' realizzata sebbene si lasci tale facolta' al cliente.
+Rimane pertanto da chiedersi se chi si fa carico dell'iterazione e' la stessa
+struttura ad oggetti (come accade sovente a detta della GoF) oppure i `Visitor`
+(si veda "GoF - ''Design Pattern'' - pagg 340-1). [[BR]]
+Il dott. Solmi, nel suo esempio sui `Visitor` snatura il significato di
+`Visitor` declassandoli a miseri `proxy` usati per evitare di esporre
+pubblicamente le operazioni come `evaluate` o `prettyPrint`. La richiesta di
+chiarimenti, inoltrata al professore esattamente un mese fa (20060720-1854), non
+ha ancora avuto risposte.[[BR]]
+A mio avviso demandare l'attraversamento della struttura a oggetti `Visitor` e'
+la soluzione migliore in termini di eleganza e chiarezza dell'algoritmo di
+visita, dal momento che la sua implementazione risiede, in tutte le sue
+componenti, proprio fra i metodi di visita degli oggetti. [[BR]]
+Faro' cosi'.
+ 
 === Appunti vari ===
 
@@ -77 +121 @@
    `getter` e `setter`) per permettere all'iteratore di accedere in maniera
    indiretta ai campi di istanza.
- * Branch: diventeranno figlie delle Expression ?
- * 20060725-1758 [gnappo] [[BR]]
-   Le API di manipolazione generiche sono dei getter e setter che agiscono
-   sull'intero modello. Per approfondire seguite il
-   [http://www.cs.unibo.it/~solmi/teaching/labss_2005-2006/EserciziProgetto2.pdf link].
-   Se non bastasse vi rimando all'
-   [http://www.cs.unibo.it/~solmi/teaching/labss_2005-2006/esercizi/labss_il_model_iterators.zip esempio]
-   del prof. Solmi: prestate attenzione alle classi !LanguageEntity e alle varie
-   Abstract* (sono particolarmente chiarificatrici).
-   
+ 
 
 
 === Operazioni aggiunte ===
 Questo e' il posto in cui rendere note le proprie scelte.
+