Variante 1

Operazioni estendibili

Note varie

La nostra Clone() e' superficiale, perche' dovrebbe essere soddisfacente per la maggior parte dei clienti, e perche' permette un certo risparmio di memoria. Da menzionarsi in documentazione.

20060724-1715
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.

20060725-1559
Si potrebbero tipizzare le liste di espressioni attualmente campi di istanza di alcune SchemeExpression. In tal modo non avremmo necessita' di cast (generici docet).
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.
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). A mio parere la prima implica uno snaturamento di cio' che e' espressione quindi percorrero' la seconda strada.