Iterator pattern: differenze tra le versioni

Versione delle 18:22, 10 mar 2014

Versione attuale delle 18:07, 1 feb 2024

(12 versioni intermedie di 8 utenti non mostrate)

Riga 1:

{{U|Iteratore|Informatica|Febbraio 2020}}

Nel contesto della [[programmazione orientata agli oggetti]], il termine '''''Iterator''''' (reso in italiano con "'''"iteratore"'''") denota uno dei più comuni e conosciuti ''[[design pattern]]''.

L'''Iterator'' risolve diversi problemi connessi all'accesso e alla navigazione attraverso gli elementi, in particolare, di una [[struttura dati]] contenitrice, senza esporre i dettagli dell'[[implementare|implementazione]] e della struttura interna del contenitore.

L'[[oggetto (informatica)|oggetto]] principale su cui si basa questo ''design pattern'' è l'[[iteratore]].

Line 5 ⟶ 6:

== Motivazioni ==

Una [[Classe (informatica)|classe]] contenitrice dovrebbe consentire l'accesso e la navigazione attraverso l'insieme degli elementi che contiene.

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 grossonotevole 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.

Line 32 ⟶ 33:

== 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 ==

Line 61 ⟶ 62:

* [[Design pattern]]

* [[Visitor]]

* [[Iteratore|Iteratore (oggetto)]]

* Quando la classe contenitore possiede [[struttura dati ricorsiva|struttura ricorsiva]], è possibile utilizzare il ''pattern [[Composite]]'' per definire una classe contenitore concreta.

* Il ''pattern'' ''[[Factory method]]'' è spesso applicato per virtualizzare la creazione di oggetti iteratore da parte delle classi contenitore.

== Altri progetti ==

{{interprogetto|commons=Category:Iterator pattern|preposizione=sull'}}

== Collegamenti esterni ==

* [{{cita web | 1 = http://web.cs.wpi.edu/~gpollice/cs509-s04/Patterns/IteratorPattern.html | 2 = Pattern iterator] | accesso = 18 dicembre 2005 | urlarchivio = https://web.archive.org/web/20060909134142/http://web.cs.wpi.edu/~gpollice/cs509-s04/Patterns/IteratorPattern.html | dataarchivio = 9 settembre 2006 | urlmorto = sì }}

{{Design Patterns Patternspattern}}

[[Categoria:PatternDesign pattern]]