Ormai anche i sassi sanno che una delle
importanti feature che sono introdotte dal framework .NET 2.0 sono gli
Iterators. GLi iterators sono in soldoni un modo alternativo agli
enumeratori per iterare, appunto, all'interno di collections, o più
genericamente di insiemi. Ma la potenza che viene messa in campo dagli
Iterators è talmente elevata, che già da un po' si possono trovare nella rete
degli esempi molto belli nei quali essi sono usati anche in modi un po' più
creativo, ad esempio come generatori di numeri primi, oppure come iteratori
del filesystem.
Questo ultimo caso, che si potrebbe riassumere nel traversare ricorsivamente
un albero, in realtà rivela dei problemi che se trascurati potrebbero avere un
impatto enorme sulle performance del codice, ma soprattutto sull'utilizzo
delle risorse da parte di quest'ultimo. Infatti, come ogni algoritmo
ricorsivo, anche quello che viene generato con gli Iterators ha la
tendenza ad impegnare una grande quantità di memoria, e quindi merita
di essere usato solo per ricorsioni poco profonde. In particolare,
l'uso ricorsivo degli iterators ha la caratteristica di generare un enorme
lavoro per il Garbage Collector.
Invece che portare un esempio di quanto sto dicendo, propongo la
lettura attenta di questo post, che
da una dimostrazione molto efficace del problema, ma che inoltre si
preoccupa di dare una altrettanto efficace indicazione di come affrontare questo
genere di algoritmi, rimanendo sempre nell'ambito degli Iterators.
L'esempio finale di elaborazione mediante Iterators del problema delle Torri di Hanoi, è
in grado grazie ad un accorto uso di uno stack, di portare il tempo di
esecuzione dai 20 secondi dell'algoritmo ricorsivo a meno di 1 secondo. Vale la
pena di investire un po' di tempo nel leggerlo.