Iterator pattern: differenze tra le versioni

Versione delle 22:22, 18 dic 2005

Versione attuale delle 18:07, 1 feb 2024

(66 versioni intermedie di 40 utenti non mostrate)

Riga 1:

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

{{da aiutare mese|motivo=scarsamente contestualizzato, manca un incipit|ottobre 2005}}

NellaNel contesto della [[Programmazione_orientata_agli_oggetti|programmazione adorientata 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]] contenitore, in particolarecontenitrice, senza esporre i dettagli di dell'[[implementare|implementazione]] e ladella struttura interna del contenitore.

Nella [[Programmazione_orientata_agli_oggetti|programmazione ad oggetti]], il termine '''''Iterator''''' (reso in italiano con '''"iteratore"''') denota uno dei più comuni e conosciuti ''[[design pattern]]''.

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

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

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

== Motivazioni ==

Una [[Classe (informatica)|classe]] contenitorecontenitrice dovrebbe consentire l'accesso e la navigazione attraverso l'insieme degli elementi che contiene. Nella programmazione a oggetti, una alternativa semplice e preferibile all'uso di indici consiste nell'aggiungere [[Metodo (programmazione)|operazioni]] all'[[interfaccia]] del contenitore.

UnNella 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 anullareannullare 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'', risolvequindi, tuttisupera questile problemisoluzioni che si possono ottenere con la pura programmazione ad oggetti mediante codice più complesso.

== Concetti fondamentali ==

Line 20 ⟶ 19:

L'idea chiave del ''pattern'' ''Iterator'' consiste nel trasferire la responsabilità dell'accesso e della navigazione attraverso gli elementi a una classe separata dal contenitore: l'iteratore.

La classe iteratore consente di visitare ad uno ad uno l'insieme degli elementi di un contenitore come se fossero ordinati in una sequenza finita. A questo scopo, un oggetto iteratore deve tenere traccia dell'ultimo elemento visitato e deve essere in grado di calcolare qual' è l'elemento successivo nella sequenza di attraversamento.

Per permettere di visitare qualunque aggregato di elementi di un tipo concreto, indipendentemente dall'iteratore specifico e dal contenitore ad esso associato, il ''pattern'' ''Iterator'' richiede la definizione di due interfacce:

Line 29 ⟶ 28:

== Struttura ==

[[File:IteratorPattern.png|thumb|upright=1.8|Struttura del pattern Iterator]]

[[Immagine:IteratorPattern.png]]

Il ''pattern'' ''iterator'' definisce due gerarchie di classi: una per i contenitori e una per gli iteratori. Le classi contenitore possono essere specializzate per tipo di elemento contenuto o per tipo di struttura in cui gli elementi sono organizzati. Le classi di iteratori sono specializzati per tipo di contenitore (iteratore concreto) e per tipo di navigazione attraverso la sequenza di elementi (iteratori specializzati).

== 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 54 ⟶ 51:

Senza [[polimorfismo (informatica)|polimorfismo]], una classe iteratore è strettamente accoppiata al suo tipo di contenitore e di elementi. Per poter cambiare la classe contenitore senza dover cambiare il codice che ne usufruisce e che attraversa gli elementi contenuti, occorre generalizzare il concetto di iteratore e trasformarlo in un'interfaccia.

Sfruttando le capacità polimorfiche di alcuni linguaggi di programmazione è possibile definire un'unica interfaccia uniforme per tutti i tipi di oggetti iteratore. Questo permette di scrivere programmi in cui l'accesso ai dati contenuti da un aggregato è completamente indipendente dalla struttura dell'aggregato stesso, purchèpurché esista una concreta implementazione dell'oggetto iteratore per una data.

Per rendere il ''pattern'' ''Iterator'' completamente indipendente dall'implementazione concreta, è necessario virtualizzare il processo di creazione delle istanze di iteratori. Di solito si provvede a questa necessità definendo un'operazione dell'interfaccia contenitore per creare un nuovo iteratore ad ogni invocazione.

== Bibliografia ==

* E.Gamma, R.Helm, R.Johnson, J.Vlissides, ''Design Patterns, Elements of Reusable Object-Oriented Software'', Pearson Education, Milano 2002, ISBN 0-201-63361-2

== Voci correlate ==

* [[Design pattern]]

* [[Visitor pattern|Visitor]]

* [[Iteratore|Iteratore (oggetto)]]

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

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

== Altri progetti ==

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

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

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

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

[[Categoria:Pattern]]

[[Categoria:PatternDesign pattern]]

[[de:Iterator]]

[[en:Iterator]]

[[es:Iterador (patrón de diseño)]]

[[fr:Itérateur (Motif de conception)]]

[[ja:イテレータ]]

[[pl:Iterator]]