Programming Languages Hacks

Il pattern Flyweight consente di riutilizzare gli oggetti in modo da poter evitare allocazioni. Questo risulta utile se:

1. gli oggetti da creare richiedono molta memoria
2. gli oggetti da creare sono molti
3. gli oggetti da creare sono costosi da creare (e distruggere) dal punto di vista computazionale
4. i vincoli impongono un sistema che non abbia cali improvvisi di performance, derivanti ad esempio dall’inizializzazione pesante di un oggetto
5. i vincoli impongono un utilizzo molto attento delle risorse

Le applicazioni vengono progettate seguendo degli approcci di progettazione formalizzati attraverso lo use case analysis e il conseguente utilizzo dei design pattern. La progettazione affronta problemi come la suddivisione delle responsabilità tra le varie classi e la loro conseguente comunicazione. In seguito, le applicazioni vengono scritte utilizzando delle API per la realizzazione di UI complesse, come le swing per Java o le WinForm per .NET.

Nelle applicazioni web viene però trascurata la progettazione legata all’usabilità e al social network, “delegando” in qualche modo quest’aspetto alla bontà di chi scriverà l’HTML, come se ogni volta ci scrivessimo da zero una dialog windows o il layout a grid in una windows application…

Yahoo! è stata la prima ad affrontare in modo rigoroso il problema dando una risposta a problemi comuni della progettazione delle pagine web:

• Prestazioni delle pagine:  34 best practices e un plugin per firefox per ricevere al volo i consigli su come ottimizzare la pagina corrente…
• Librerie UI: componenti come modal dialog, layout manager, treeview, … progettati per essere crossbrowser. Molto spesso si abbinano queste librerie a progetti più generici come JQuery per creare i propri personali effetti grafici non presenti nelle librerie di Yahoo!
• Design Pattern Library: risolvono problemi ricorrenti nelle applicazioni web

Proprio di quest’ultimo faremo una carrellata dei pattern citati:

Search

• Search Pagination, Item Pagination e Carousel
  • Problema: si vuole visualizzare il risultato di una ricerca e non è possibile mostrarli tutti in una pagina.
  • Soluzione:
    • creare un paginator che contiene gli elementi “Prev <- 2 3 4 5 6 7 8 9 10 11 -> Next”, dove il link corrente (7) non è cliccabile (Search Pagination).
    • creare una semplice navigazione “1-5 of 32 First | < Prev | Next > | Last” per ogni elemento, in modo da far mantenere all’utente il focus sulla navigazione avanti/indietro (Item Pagination)
    • creare una navigazione avanti/indietro molto grafica, da utilizzare in un ambito dove si scorre tra risultati che prevedono grafica (Carousel)
  • Librerie: YUI Paginator e YUI Carousel

Navigation

• Breadcrumbs.
  • Problema: l’utente si trova in una pagina del sito da cui non è agevole accedere alle altre sezioni e potrebbe provenire da un altro sito e non avere quindi la percezione di dove si trova collocato nel sito che stà visitando.
  • Soluzione: presentare una lista orizzontale di link che rappresenta un “albero compatto” della collocazione del link corrente all’interno della struttura di un sito
  • Librerie: .NET SiteMapPath
• Alphanumeric Filter Links.
  • Problema: l’utente ricerca un elemento di cui conosce solo la lettera iniziale.
  • Soluzione: consentire una ricerca partendo dalla lettera iniziale
• Module Tabs.
  • Problema: esistono diversi pannelli che non possono essere visualizzati contemporaneamente e che comunque non ci sarebbe sufficiente spazio e di cui è necessario eseguire uno switch senza cambiare pagina web corrente.
  • Soluzione: creare una lista di tab separati da un ‘|’, il cui click causa l’attivazione lato client solo del pannello interessato, disattivato il precedente. Il tab è una rappresentazione della categorizzazione delle cartelline di lavoro tramite l’uso di linguette (tab).
  • Librerie: YUI TabView
• Navigation Tabs
  • Problema: esistono 3-10 macrocategorie sufficientemente stabili da rappresentare, le quali devono essere utilizzate per indicare la posizione dell’utente all’interno del sito. Il cambio di categoria deve causare un completo caricamento di una nuova pagina.
  • Soluzione: utilizzare tab in alto, eventualmente con sottocategorie al click. Se le categorie sono troppe per lo spazio orizzontale, creare i tab sulla sinistra della pagina

Browsing

• Page Grids
  • Problema: si devono creare/gestire molteplici pagine, le quali potrebbero essere costruite da gruppi di lavoro differenti
  • Soluzione: creare un template comune a griglia, in cui ogni cella è destinata a contenere il lavoro di un gruppo. Bisogna inoltre creare un css comune che contenga quanto richiesto da tutti i gruppi di lavoro
  • Librerie: YUI Grids. Consente di creare layout a grid tramite div e css cross browser.

Selection

• Auto Complete
  • Problema: si deve inserire in un campo di testo un valore difficile da ricordare e che quindi si presta a errori di scrittura
  • Soluzione: fornire una textbox con supporto all’autocompletamento
  • Librerie: YUI Autocomplete
• Calendar Picker
  • Problema: l’utente deve inserire o trovare un’informazione basata su data o su data range
  • Soluzione: fornire una textbox o due textbox che propongono di compilare automaticamente il campo sulla base della selezione effettuata dall’utente all’interno di un calendario grafico
  • Librerie: YUI Calendar

Rich Interation

• Drag and Drop Modules
  • Problema: l’utente deve personalizzare il layout della propria pagina senza lasciare la pagina corrente
  • Soluzione: fornisci il drag dei moduli. Suggerisci dove poter effettuare il drop incorniciando le aree “droppabili” (pattern Drop Invitation)
  • Librerie: YUI Drag & Drop
• Cursor Invitation
  • Problema: l’utente deve capire che può interagire con un oggetto della pagina
  • Soluzione: cambia il puntatore del mouse a seconda dell’operazione da eseguire
• Tool Tip Invitation
  • Problema: l’utente deve capire cosa succederà al click del mouse su un oggetto che non sia un semplice link
  • Soluzione: fornisci un tooltip come “Clicca per modificare”
  • Librerie: YUI Tooltip
• Hover Invitation
  • Problema: l’utente deve capire quale effetto scatenerà al “semplice” click del mouse su un oggetto che scatena un certo cambio di stato
  • Soluzione: fornisci un feedback immediato al passaggio del mouse sull’elemento mostrando un avvertimento su cosa succederà
• Animate Transition
  • Problema: l’utente deve percepire gradualmente che un oggetto sta cambiando la sua relazione con lo spazio occupato nella pagina
  • Soluzione: fornisci un’animazione che gradualmente faccia cambiare la relazione con lo spazio
  • Librerie: YUI Animation
• Dim Transition e Brighten Transition
  • Problema: l’utente deve percepire che un elemento della pagina è diventato di secondaria importanza, non disponibile o non editabile. Questo stato deve poi poter essere ripristinato, facendo segnalare la rinnovata attività dell’elemento
  • Soluzione: definisci lo stato dim e lo stato brighten. Il primo si verifica nel momento in cui diventa di secondaria importanza, mentre il secondo ripristina l’elemento
  • Librerie: YUI Animation
• Collapse Transition e Expand Transition
  • Problema: l’utente deve poter comprimere un certo elemento che ritiene di secondaria importanza. Viceversa, l’utente deve poter espandere un elemento precedentemente compresso o ottenere dettagli su un certo elemento
  • Soluzione: comprimi o espandi utilizzando una rapida animazione (0.5 secondi)
  • Librerie: YUI Animation
• Cross Fade Transition
  • Problema: l’utente deve percepire che la vista di un oggetto sta per essere rimpiazzata con una nuova vista
  • Soluzione: esegui il fade out della rimpiazzata, mentre la nuova entrerà in fade in
  • Librerie: YUI Animation
• Fade In Transition e Fade Out Animation
  • Problema: l’utente deve percepire che un elemento è stato aggiunto o rimosso alla pagina
  • Soluzione: porta l’opacità di un oggetto dal 0% (100%) al 100% (0%) eventualmente attivando (disattivando) il focus sull’elemento
  • Librerie: YUI Animation
• Self Healing Transition
  • Problema: l’utente deve percepire che un elemento all’interno di una lista è stato rimosso
  • Soluzione: esegui il fade out dell’elemento lasciando un buco sull’elemento rimosso. Successivamente esegui il pattern Slide.
• Slide Transition
  • Problema: l’utente vuole percepire che un elemento non popup è stato aggiunto o rimosso dalla pagina e vuole percepire la collocazione spaziale del nuovo elemento all’interno della pagina
  • Soluzione: unisci il fade con lo slide
  • Librerie: YUI Animation
• Spotlight
  • Problema: l’utente vuole percepire che un valore è cambiato nell’interfaccia
  • Soluzione: cambia colore dell’elemento istantaneamente in modo che sia visibile e ripristina al colore del background nel giro di un secondo
  • Librerie: YUI Animation

Social: Rating & Reviews

• Architecture of a Review
  • Problema: una webapp deve presentare voti e recensioni con una varietà di informazioni aggiuntive
  • Soluzione: gli elementi devono essere raggruppati per Target Element (info sul prodotto da recensire), Review Element (voti + recensioni) e Form Element (giudizio utente). Ogni elemento può essere ulteriormente scomposto secondo la struttura riportata nel pattern
• Rating an Object
  • Problema: un’utente vuole lasciare la propria opinione su un oggetto, con interruzioni minime a qualsiasi altro task su cui stà lavorando
  • Soluzione: mostra votazione pronta all’uso, combinando la tecnica Hover Invitation e invitando l’utente a votare in presenza di un valore vuoto
• Vote to Promote
  • Problema: l’utente vuole promuovere un contenuto in una comunity in modo che tale contenuto abbia maggior rank e venga mostrato maggiormente, in una forma democratica
  • Soluzione: fornisci un meccanismo di voto “one-time” per l’utente; evidenzia gli elementi più votati mostrandone il numero di voti; fornisci il voto solo a seguito del consumo dell’elemento: alla fine dell’articolo o all’interno delle pagine esterne tramite snippet esterno da includere
• Writing a Review
  • Problema: l’utente vuole condividere la propria opinione su un oggetto in modo più accurato di un semplice voto
  • Soluzione: fornisci una form di review che contenga info quantitative (voti vari) più info qualitative (recensione stessa) con associate delle linee guida e varie altre regole

Social: Reputation

Un sistema di reputazione viene definito nel momento in cui si ha necessità di garantire un maggiore utilizzo del servizio o una qualità nell’utilizzo. Il pattern The Competitive Spectrum fornisce delle linee guida per scegliere il tipo di sistema di reputazione da realizzare. Nel pattern, la community viene definita in termini di competitività: la combinazione degli obiettivi individuali, delle azioni che influiscono sui bisogni della comunità e del grado richiesto di confronto tra i membri. Le linee guida da adottare dipendono dal livello di competitività richiesta:

• Caring
  • Obiettivo: i membri vogliono aiutare altri membri
  • Reputazione: consente di far identificare i membri “senior” all’interno della community
  • Strumenti: fai indossare una o più Identifying Labels al profilo di un utente in modo che i “bollini” guadagnati caratterizzino l’influenza del membro nella community
• Collaborative
  • Obiettivo: i membri vogliono cooperare per raggiungere un obiettivo in gran parte condiviso
  • Reputazione: consente di far identificare i membri che sono fedeli alla community
  • Strumenti: decora il profilo utente con dei Named Levels che consentano di stabilire facilmente, senza ambiguità e senza alcuna accezione offensiva la fedeltà dei membri
• Cordial
  • Obiettivo: i membri hanno i loro personali scopi, ma questi non vanno a contrastare con quelli condivisi dalla community
  • Reputazione: consente di far identificare i membri che hanno valori e interessi che la community reputa positivi
  • Strumenti: fornisci dati statistici correlati a un utente. In aggiunta, il pattern Top X consente di identificare facilmente gli utenti che producono interventi con maggiore qualità
• Competitive
  • Obiettivo: i membri hanno gli stessi obiettivi, ma per raggiungerli devono competere tra di loro
  • Reputazione: consente di far mostrare alla community i progressi raggiunti da un certo utente per suscitare ammirazione (o invidia)
  • Strumenti: fornisci una facile comparazione decorando al profilo un “livello saiyan” agli utenti tramite dei Numbered Levels. Fornisci delle soddisfazioni tramite premi come “luccicanti badge da decorare al profilo” tramite l’uso dei Collectible Achievements, in cui i premi sono legati a diversi obiettivi di difficoltà crescente (da “hai completato il profilo” a “sei il più attivo nella community”)
• Combative
  • Obiettivo: i membri condividono obiettivi opposti. Il raggiungimento dell’obiettivo di uno nega il raggiungimento dell’obiettivo dell’altro.
  • Reputazione: consente di far mostrare alla community i progressi e i regressi raggiunti da un certo utente per suscitare ammirazione o scherno…
  • Strumenti: utilizza il pattern Points per rappresentare la performance di un utente e poterla incrementare o diminuire a seconda dei risultati. Fai un rank dei membri tramite o Top X o una Leaderboard (un Top X più aggressivo, che rappresenta ad esempio le top 3 della settimana)

A queste tecniche spesso si combina quella della Sign-in Continuity, in cui il voto di un utente viene proposto a patto di registrarsi o di autenticarsi, ma la registrazione non deve perdere il contesto (utile una dialog).

Dal blog di Adrian Florea (e quindi dal libro di Uwe Aßmann) mi ha colpito molto questa metafora aritmetica per esprimere il concetto dei design pattern:

“The basic solution strategy of a design pattern is factoring:

a * b + a * d = a * (b + d)

Design patterns are the “binomial formulas” of software engineering!“

Infatti quello che fanno i design pattern è fattorizzare, mettere in comune aspetti altrimenti ripetuti, come:

• porzioni di codice in un metodo: Pattern Template
• espressioni, salti condizionati: Pattern Strategy, State, Template, Factory, … in generale l’utilizzo sensato del polimorfismo (cioè il senso dei pattern)
• metodi interi: spesso sintomo di cattiva assegnazione di responsabilità. I pattern consentono di individuare le responsabilità in modo da condividere gli stessi metodi nell’ambito della stessa classe padre

Un ottimo articolo che ne parla è quello di UGIdotNET.

Normalmente quando scriviamo codice capita di scrivere proprietà statiche: si pensi al pattern Singleton. Lo scopo di questo pattern è proprio assicurare la condivisione degli elementi, per ragioni di efficienza o di consistenza.

Il pattern funziona bene in contesti “normali”: è implementato mediante un campo/proprietà statico e quindi condiviso nell’ambito dell’applicazione Console/Windows che sviluppiamo. Se però ci spostiamo in contesti distribuiti il pattern non è in realtà così efficace:

In contesti distribuiti, i campi statici sono condivisi solo nell’ambito della stessa richiesta

Quindi in una nuova richiesta viene “dimenticato” il valore assunto degli stessi campi statici in altre richieste. I campi statici nascono invece con lo scopo di avere memoria globale di un’informazione. Quindi, come regola generale:

Il concetto di “campi static” dovrebbe sempre essere virtualizzato

Questo significa che, come possibile soluzione, la proprietà statica deve essere acceduta mediante una classe astratta CacheManager, che:

1. è ottenibile come Singleton “puro”, cioè come proprietà statica a cui siamo tanto abituati. Avremo quindi un metodo CacheManager.GetInstance che restituisce tale istanza, condivisa solo nell’ambito della richiesta corrente
2. consente metodi come SetPrinterSingleton o GetPrinterSingeton che restituiscono tali valori in cache
3. l’implementazione di tale metodi varia a seconda del tipo concreto in uso

Il terzo punto significa che avremo diverse implementazioni, come StaticCacheManager o WebApplicationCacheManager, in cui la prima prenderà valori nel modo classico, tramite proprietà di istanza, mentre la seconda implementazione li prenderà dalle variabili “Application” del nostro web site.

La scelta di quale implementazione concreta utilizzare è demandata al momento in cui viene creato internamente l’istanza unica di CacheManager, che ci restituirà l’istanza corretta sulla base del principio “Dependency Injection“: viene specificato cosa creare mediante file di configurazione e/o Reflection.

Molto comodo risulta infine utilizzare un Singleton con “shortcut”: invece di scrivere

public abstract class CacheManager {
    public static CacheManager GetInstance() {
        return ServiceLocator.GetCacheManager(); // usa reflection
    }
    public abstract Printer GetPrinterSingleton();
}

scriveremo una forma molto più compatta da utilizzare per il “client” della classe:

public abstract class CacheManager {
    public static CacheManager GetInstance() {
        return ServiceLocator.GetCacheManager(); // usa reflection
    }
    public static Printer GetPrinterSingeton() {
        return GetInstance().GetPrinterSingleton();
    }
    protected abstract Printer GetPrinterSingleton();
}

Che verrà quindi utilizzato in questo modo:

public sealed class Printer {
    private Printer() {
    }
    public static Printer GetInstance() {
        // lock regione critica omessi per semplicita'
        Printer printer = CacheManager.GetPrinterSingleton();
        if(printer == null) {
            // il set restituisce la stessa istanza passata per parametro
            printer = CacheManager.SetPrinterSingleton(new Printer());
        }
        return printer;
    }
}

Si può anche esprimere in una forma succinta, utilizzando l’operatore di null coalescing di C#:

public sealed class Printer {
    private Printer() {
    }
    public static Printer GetInstance() {
        return CacheManager.GetPrinterSingleton() ?? CacheManager.SetPrinterSingleton(new Printer());
    }
}

Si può infine completare l’implementazione garantendo la mutua esclusione utilizzando l’approccio di William Pugh:

public sealed class Printer {
    private Printer() {
    }
    public static Printer GetInstance() {
        return SingletonHolder.GetInstance();
    }

    class SingletonHolder {
        static SingletonHolder() { }
        static Printer GetInstance() {
            return CacheManager.GetPrinterSingleton() ?? CacheManager.SetPrinterSingleton(new Printer());
        }
    }
}

Attenzione: si potrebbe pensare che lo stesso concetto si applichi anche al pattern Flyweight. In realtà questo pattern (a differenza dell’esempio riportato nell’articolo in Wikipedia) non dovrebbe prevedere una mappa statica, ma a livello istanza, quindi la regola descritta è comunque soddisfatta.

In pratica la regola da seguire è questa:

Campi/proprietà statiche hanno senso solo nel contesto del pattern Singleton, e in tal caso il concetto di “campi static” deve essere virtualizzato tramite un CacheManager, a sua volta creabile tramite la versione “standard” del pattern Singleton

In .NET è spesso necessario ottenere la scalabilità delle applicazioni. Immaginiamo di aver scritto un bellissimo software che richiede a un sistema esterno il permesso per richiedere un mutuo aziendale. Saranno presenti numerosi scambi di messaggi tra il nostro sistema e il sistema esterno in questione, che possono comportare dei lunghi tempi di attesa.

Immaginiamo ora che in questo lasso di tempo avvengano 100.000 richieste verso la nostra applicazione. Possiamo immaginare soluzioni più o meno eleganti, come pool di thread o gerarchie di processi ma queste hanno efficacia solo con molteplici processori. Anche se è una soluzione che solo ora sta diventando praticabile per un computer “normale”, grazie ai processori multi core, non è comunque una soluzione “altamente” scalabile: è infatti subordinata all’architettura del sistema che esegue la nostra applicazione.

Si utilizzano quindi normalmente diversi approcci di computer clustering. Tra i possibili tipi di clustering, esistono:

• Fail-over clustering: il funzionamento delle macchine è continuamente monitorato, e quando uno dei due host smette di funzionare l’altra macchina subentra. Lo scopo è garantire un servizio continuativo
• Load-balancing clustering: sistema nel quale le richieste di lavoro sono inviate alla macchina con meno carico
• High Performance Computing clustering: le macchine suddividono i processi di un job su più macchine, al fine di guadagnare in prestazioni

In realtà, i clustering descritti sono figli di due pattern (presi da POSA):

• Broker (o la sua versione “leggera” Client-Dispatcher-Server): supporta il coordinamento e la comunicazione tra sistemi distribuiti eterogenei. Consente di mantenere trasparente la localizzazione dei Server, in modo da poterli cambiare dinamicamente per ottenere un bilanciamento di carico
• Master-Slave: supporta tolleranza d’errore, calcolo parallelo e accuratezza computazionale tramite ridondanza. Esiste un componente Master che suddivide e distribuisce il lavoro a componenti Slave identici. Gli Slave calcolano il risultato parziale e lo restituiscono al Master, il quale assembla i risultati parziali ottenuti per ottenere quello definitivo

Il protocollo con cui questi sistemi dialogano non è un problema, se si combina anche il pattern Forward-Receiver, che consente di definire un protocollo di comunicazione trasparente.

Nel nostro caso, risulta eccessivo dividere il lavoro in più sottolavori: quello che vorremmo è semplicemente smistare la richiesta al server più libero in modo da ottenere una scalabilità. Vorremmo quindi implementare il pattern Broker.

Fortunatamente, .NET ci viene incontro e ci fornisce un pattern Broker “pronto all’uso”: il .NET remoting. In MSDN esiste infatti la guida su come implementare il pattern Broker utilizzando .NET remoting.

Ma se si utilizza Microsoft Windows Server 2003, allora è possibile utilizzare una grande scorciatoia per il Load-Balancing clustering (oltre a quella appena vista): le Windows Server 2003 Clustering Services. Consentono di costruire un cluster di server. Il cluster è dotato di un indirizzo IP virtuale (xxx.yyy.zzz.kkkk), che quando richiesto trova corrispondenza con un indirizzo IP reale della macchina fisica più libera. In questo modo, è sufficiente creare in alternativa:

• una dll acceduta tramite .NET remoting
• un web service

e replicarlo in tutte le macchine fisiche. A questo punto, quando accederemo all’indirizzo IP xxx.yyy.zzz.kkkk e richiederemo il servizio interessato, il sistema operativo ci smisterà automaticamente alla macchina più libera. Non c’è bisogno di alcuna modifica nel nostro codice, stupefacente no??

Per maggiori informazioni, si veda l’ottimo articolo su come scrivere applicazioni “clusterizzate” in c# di Gerald Gibson Jr.

I virtual proxy forniscono un rappresentante di un oggetto in modo da gestirne il caricamento su richiesta, anche noto come lazy initialization.

Se immaginiamo un file word di 500 pagine, con più di 1000 immagini, il caricamento dovrebbe impegnare molto tempo e molte risorse. In realtà quel che succede è che ogni immagine non viene caricata, ma solo “dichiarata”. Nel nostro file “PROVA.DOC” ci saranno informazioni utili come width/height dell’immagine in modo che la “dichiarazione” dell’immagine consenta la corretta impaginazione.

Fin qui tutto bene, ma ora immaginiamo di aver fatto scorrere tutte le 500 pagine e di aver visto tutte le 1000 immagini. Cosa succede? Semplice: tutte le immagini sono state effettivamente caricate e abbiamo consumato molta, molta RAM (aaarghhh!!) .

Il problema (quì molto romanzato…) sembra però più serio del previsto. Citiamo il pattern Proxy:

Il design pattern Proxy fornisce un surrogato o un segnaposto di un altro oggetto per controllare l’accesso a tale oggetto.

Il client che utilizza il Proxy ne è inconsapevole: sa solamente che il comportamento atteso della classe deve essere rispettato. L’indirezione introdotta dal Proxy deve quindi essere trasparente e l’utente non può intervenire su di essa. Il clean quindi non può (e non deve) essere gestito manualmente.

Abbiamo quindi il seguente schema:

• una classe R reale
• un virtual proxy V che gestisce il caricamento su richiesta di R
• un client, che utilizza V ma che in realtà è convinto di utilizzare R

Dopo tanto patire, senza ulteriori preliminari, questa è la soluzione che mi sembra più corretta (vi apparirà forse scontata ora che la leggete, ma vi garantisco che cercando e ricercando su Google nessuno ne parla…). Il nuovo contesto è il seguente:

• una classe R reale
• un cache proxy C, che memorizza fino a n classi reali R
• un virtual proxy V, che se necessario richiede a C di ottenere la classe reale R
  • C restituisce la cache entry se esiste, o crea il corrispondente R memorizzando il risultato in cache
  • se nella memorizzazione del nuovo cache entry viene superato il limite n di cache:
    • viene liberata la cache eliminando l’elemento meno richiesto (least frequently used)
    • vengono notificati tutti gli V che ne facevano uso, che impostano a null la classe reale R utilizzata richiamando funzioni di liberazione della memoria come la garbage collection. La notifica si deve basare su un protocollo condiviso tra V e C, utilizzando ad esempio il design pattern Observer.
• un client, che utilizza V ma che in realtà è convinto di utilizzare R

Un modo semplice di implementare la tecnica “least frequently used” è la strategia “move-to-front” descritta in Pattern Oriented Software Architecture: a ogni richiesta di una cache entry l’elemento viene spostato alla testa di una lista. Quando è necessario liberare memoria possono essere eliminati gli elementi alla coda della lista. Questo può essere implementato (ad es. in Java) estendendo i metodi get() e put() di una Map.

Questa (da quanto ne so) è una soluzione “casalinga”, che non si basa su tecniche o pattern noti. Perciò qualunque suggerimento/critica sarà più che apprezzata…