Nella programmazione a oggetti, un'alternativa semplice e preferibile all'uso di indici (come accade ad esempio per gli [[array]]) consiste nell'aggiungere [[Metodo (programmazione)|operazioni]] all'[[interfaccia (informatica)|interfaccia]] del contenitore. Questa soluzione ha il notevole vantaggio che, se l'interfaccia è ben definita, consente di annullare la dipendenza da dettagli interni del contenitore, ma ciò presenta alcuni inconvenienti:
#* '''Sovraccarico dell'interfaccia del contenitore.''': Le operazioni aggiunte sovraccaricano l'interfaccia preesistente della classe contenitore.
#* '''Mancanza di punti di accesso multipli.''': Le operazioni sono centralizzate nella classe contenitore. Questo non consente di effettuare contemporaneamente più visite indipendenti agli elementi dello stesso contenitore.
#* '''Supporto carente per metodi di navigazione specializzati.''': Quando i contenitori possiedono una struttura complessa, non di rado vi sono diversi e ugualmente utili modi di attraversarne l'insieme degli elementi contenuti. Un'interfaccia centralizzata si adatta male a questa situazione, perché richiede l'aggiunta di più operazioni specializzate, esacerbando il problema del sovraccarico.
Il ''design pattern'' ''Iterator'', quindi, supera le soluzioni che si possono ottenere con la pura programmazione ad oggetti mediante codice più complesso.
== Partecipanti ==
* ''';Iterator''': definisce un'interfaccia per attraversare l'insieme degli elementi di un contenitore e accedere ai singoli elementi.
* ''';ConcreteIterator''': implementa l'interfaccia Iterator tenendo traccia della posizione corrente nel contenitore e calcolando qual è l'elemento successivo nella sequenza di attraversamento.
* ''';Aggregate''': definisce un'interfaccia per creare un oggetto Iterator.
* ''';ConcreteAggregate''': implementa l'interfaccia di creazione dell'Iterator e ritorna un'istanza appropriata di ConcreteIterator.
== Benefici e conseguenze ==
|