| 1 | | = 1 = |
| 2 | | * prodotti aggiungibili a run-time come a tempo di compilazione -> (prototype factory and old factory) under template factory |
| 3 | | * unica interfaccia esposta al cliente per la creazione dei prodotti |
| 4 | | * riduzione del consumo di memoria: singleton per il factory manager (non per il prototype, cosi il cliente ...) cosiccome |
| 5 | | per l'old-factory. |
| 6 | | * facilitazione della configurazione dei prodotti al solo tempo di costruzione: ai vari metodi create e' sempre passata una |
| 7 | | lista di argomenti. Per quanto concerne la necessita' di configurare i prototipi sara' il cliente stesso a provvedere |
| 8 | | ridefinendo il metodo create della prototype factory. |
| | 1 | = Variante 1 - Prodotti estendibili = |
| 10 | | = 2 = |
| | 3 | === Introduzione === |
| | 4 | * una sorta di framework per lo sviluppo di linguaggi a partire da MiniScheme |
| | 5 | * prodotti aggiungibili a run-time come a tempo di compilazione -> (prototype factory and old factory) under template factory |
| | 6 | * unica interfaccia esposta al cliente per la creazione dei prodotti |
| | 7 | * riduzione del consumo di memoria: singleton per il factory manager (non per il prototype, cosi il cliente ...) cosiccome |
| | 8 | per l'old-factory. |
| | 9 | * facilitazione della configurazione dei prodotti al solo tempo di costruzione: ai vari metodi create e' sempre passata una |
| | 10 | lista di argomenti. Per quanto concerne la necessita' di configurare i prototipi sara' il cliente stesso a provvedere |
| | 11 | ridefinendo il metodo create della prototype factory. |
| 12 | | * operazioni polimorfe e modulari sul modello -> visitor (modualrita'++ e algoritmo esterno al modello) |
| 13 | | * la visita e` gestita in maniera autonoma dal visitor, che restituisce il controllo soltanto una volta terminato per intero la visita |
| 14 | | * numero di costrutti non soggetto a cambiamenti -> abstract factory under singleton |
| 15 | | * api specifiche permettono al visitor l'attraversamneto dell'albero |
| 16 | | * iterator esterni (algoritmo esterno :)) |
| | 13 | = Variante 2 - Operazioni estendibili = |
| | 14 | |
| | 15 | === Introduzione === |
| | 16 | * una sorta di framework per lo sviluppo di interpreti per il linguaggio Minischeme |
| | 17 | * estendibilita' delle operazioni -> rendere indipendente il modello dalle relative operazioni (attaccare il concetto di incapsulamento fra dati e operazioni, croce e delizia del paradigma a oggetti) -> mezzi utilizzati: esternare ogni algoritmo dal modello e dove possibile, rendere le operazioni modualari |
| | 18 | |
| | 19 | == Modello == |
| | 20 | * numero di costrutti non soggetto a cambiamenti -> factory under singleton |
| | 21 | * le api di manipolazione permettono al visitor l'attraversamento dell'albero |
| | 22 | * (albero eterogeneo && obiettivi di iterazione e visita polimorfica) -> aggiunta di `Entity` per permettere al cliente completa liberta' sebbene all'`Interpreter` interessino solo `Expression` (e ` Definition`?) |
| | 23 | * implementazioni di default come per `Value` |
| | 24 | * api di manipolazione generica implementate con enumerazioni invece che con index per aumentare la tipizzazione |
| | 25 | |
| | 26 | == Visitor == |
| | 27 | * la visita e' gestita in maniera autonoma dal visitor, che restituisce il controllo soltanto una volta terminato per intero la visita |
| | 28 | * uso di campi interni per permettere il passaggio dell'ambiente di valutazione (un'informazione indispensabile) |
| | 29 | * metodo `visit()` overloaded in modo da demandare alla vm la selezione dei metodi nel caso si voglia trattare con `Entity` |
| | 30 | |
| | 31 | == Iterator == |
| | 32 | * iterator esterni il cliente ha in mano il controllo dell'iterazione |
| | 33 | * l'algoritmo di attraversamento risiede all'interno dell'iterator e non all'interno del modello per perseguire l'estendibilita' delle operazioni richieste |
| | 34 | * modularizzato in `ModelIterator` (iteratore sull'intero modello) ed `EntityIterator` (iteratore sui figli di una entita') |
