Changes between Version 11 and Version 12 of Variante1

Timestamp:

Jul 26, 2006, 5:08:18 PM (18 years ago)

Author:

gnappo

Comment:

--

Variante1

@@ -5 +5 @@
 
 20060724-1715 [[BR]]
-In realta' implementare la `Clone()` per i prodotti base non e' necessaria giacche' la factory istanzia in maniera corretta tali prodotti. Tale funzione diventa invece _indispensabile_ per chi vuole aggiungere nuovi prodotti a run-time per una successiva creazione. Il prof. Solmi ha adottato una soluzione abbastanza elegante: ha definito una superclasse astratta dove clone solleva eccezione di default. Chi vorra' aggiungere nuovi prodotti sara' obbligato a ridefinirsi tale metodo per non incorrere in eccezioni.
+In realta' implementare la `Clone()` per i prodotti base non e' necessario giacche' la factory istanzia gia' in maniera corretta tali prodotti. Tale funzione diventa invece _indispensabile_ per chi vuole aggiungere nuovi prodotti a run-time per una successiva creazione. Il prof. Solmi ha adottato una soluzione abbastanza elegante nell'esempio di IL con factory estendibili: ha definito una superclasse astratta dove clone solleva eccezione di default. Chi vorra' aggiungere nuovi prodotti sara' obbligato a ridefinirsi tale metodo per non incorrere in eccezioni.
 
 20060725-1559 [[BR]]
-Si potrebbero tipizzare le liste di espressioni attualmente campi di istanza di alcune !SchemeExpression. In tal modo non avremmo necessita' di cast (generici docet). [[BR]]
-Tutte le SchemeExpression<Value> potrebbero avere come campo d'istanza lo scheme value associato (da istanziarsi al momento della creazione dell'espressione) anziche il valore come tipo primitivo. Attualmente gli scheme-value vengono creati solo al momento della valutazione. Se fossero creati subito il metodo prettyPrint potrebbe semplicemente riutilizzare il metodo toString insito negli scheme-valori. La soluzione e' piu' elegante anche se richiede un consumo di memoria maggiore.[[BR]]
+Nota minore:Si potrebbero tipizzare le liste di espressioni attualmente campi di istanza di alcune !SchemeExpression (e.g. !SchemeExpressionAnd). In tal modo non avremmo necessita' di cast (generici docet). [[BR]]
+Tutte le SchemeExpression<Value> potrebbero avere come campo d'istanza lo scheme value associato (da istanziarsi al momento della creazione dell'espressione) anziche il valore come tipo primitivo. Attualmente gli scheme-value vengono creati solo al momento della valutazione. Se fossero creati subito il metodo prettyPrint potrebbe semplicemente riutilizzare il metodo toString insito negli scheme-valori. La soluzione e' piu' elegante anche se richiede un consumo di memoria leggermente maggiore. (<-la proposta e' stata implementata)[[BR]]
 Nello scrivere la prettyPrint ci si accorge dell'utilita' di averne una anche per !SchemeBranch e !SchemeDefinition in quanto contenute in altre !SchemeExpression. Le soluzioni percorribili sono dunque due: la prima e' rendere !SchemeExpression sia i branch che le definition, la seconda esporre dei getter specifici che ritornano espressioni (trattasi di aggiramento, !SchemeBranch gia' li offre). A mio parere la prima implica uno snaturamento di cio' che e' espressione quindi percorrero' la seconda strada.
+
+20060726-1652 [[BR]]
+In un passo delle specifiche riguardanti variante 1 si fa riferimento alla configurazione dei prodotti durante la costruzione. A tal proposito sorge un dubbio riguardo ai prototipi: come favoriamo la configurazione dei prototipi? Attualmente vengono passati degli argomenti al metodo create della prototype factory ma essi vengono ignorati in quanto tale metodo ritorna semplicemente un clone (di piu' non puo' essere fatto visto che non possiamo conoscere come i prodotti futuri dovranno essere configurati). A questo punto in documentazione andrebbe aggiunto: "![...] qualora il cliente prevedesse una fase di configurazione durante la creazione di un prodotto, dovra' egli stesso ridefinire una !PrototypeFactory in cui il metodo create assolva a tale compito".