Perché Iterator definisce l'operazione remove()?

Question

In C#, l'interfaccia IEnumerator definisce un modo per attraversare una raccolta e osservare gli elementi. Penso che questo sia tremendamente utile perché se si passa a IEnumerable<T> a un metodo, non si modifica la fonte originale.

Tuttavia, in Java, Iterator definisce l'operazione remove su (facoltativamente!) Consentire l'eliminazione di elementi. Non vi è alcun vantaggio nel passare Iterable<T> a un metodo poiché tale metodo può ancora modificare la raccolta originale.

remove s' optionalness è un esempio del refused bequest odore, ma ignorando che (già discusso here) Sarei interessato alle decisioni di progettazione che hanno indotto un evento remove da attuare sull'interfaccia.

Quali sono le decisioni di progettazione che hanno portato a remove aggiunto a Iterator?

Per mettere un altro modo, qual è la decisione di progettazione C# che non ha esplicitamente remove definito su IEnumerator?

Answer 1

Iterator è in grado di rimuovere elementi durante l'iterazione. Non è possibile ripetere la raccolta utilizzando l'iteratore e rimuovere elementi dalla raccolta di destinazione utilizzando il metodo remove() di tale raccolta. Otterrai ConcurrentModificationException alla prossima chiamata di Iterator.next() perché l'iteratore non può sapere come esattamente la collezione è stata cambiata e non può sapere come continuare ad iterare.

Quando si utilizza remove() di iteratore, sa come è stata modificata la raccolta. Inoltre in realtà non è possibile rimuovere alcun elemento della collezione ma solo quello attuale. Questo semplifica la continuazione dell'iterazione.

Per quanto riguarda i vantaggi di passare iteratore o Iterable: è sempre possibile utilizzare Collection.unmodifireableSet() o Collection.unmodifireableList() per impedire la modifica della raccolta.

Answer 2

Ci sono situazioni in cui si desidera essere in grado di rimuovere elementi utilizzando l'iteratore perché è il modo più efficiente per farlo. Ad esempio, quando si attraversa una struttura di dati collegata (ad esempio un elenco collegato), la rimozione mediante l'iteratore è un'operazione O(1) ... rispetto a O(N) tramite le operazioni List.remove().

Naturalmente, molti collezioni sono progettati in modo che modificando la raccolta durante una collezione con qualsiasi altro mezzo di Iterator.remove() si tradurrà in una ConcurrentModificationException.

---

Se si dispone di una situazione in cui non si desidera consentire la modifica tramite un iteratore collezione, avvolgendolo con Collection.unmodifiableXxxx e usando il suo iteratore avrà l'effetto desiderato. In alternativa, penso che Apache Commons fornisce un semplice wrapper iteratore immodificabile.

---

proposito IEnumerable soffre dal medesimo "odore" come Iterator. Dai uno sguardo al metodo reset(). Ero anche curioso di sapere come la classe C# LinkedList si occupa del problema di rimozione O(N). Sembra che lo faccia per esponendo le parti interne della lista ...nella forma delle proprietà First e Last i cui valori sono LinkedListNode riferimenti. Ciò viola un altro principio di progettazione ... ed è (IMO) molto più pericoloso di Iterator.remove().

Answer 3

È probabilmente dovuto al fatto che la rimozione di elementi da una raccolta mentre si esegue l'iterazione è sempre stata una causa di errori e comportamento strano. Dalla lettura della documentazione suggerirebbe che Java applica in fase di esecuzione remove() viene chiamato solo una volta per chiamata a next(), il che mi fa pensare che sia stato appena aggiunto per impedire alle persone di rovinare la rimozione dei dati da un elenco durante l'iterazione.

Answer 4

Questa è in realtà una funzionalità eccezionale di Java. Come forse sapete, quando si scorre un elenco in .NET per rimuovere elementi (di cui esistono diversi casi d'uso), si hanno solo due opzioni.

var listToRemove = new List<T>(originalList); 
foreach (var item in originalList) 
{ 
    ... 
    if (...) 
    { 
     listToRemove.Add(item) 
    } 
    ... 
} 

foreach (var item in listToRemove) 
{ 
    originalList.Remove(item); 
} 

o

var iterationList = new List<T>(originalList); 
for (int i = 0; i < iterationList.Count; i++) 
{ 
    ... 
    if (...) 
    { 
     originalList.RemoveAt(i); 
    } 
    ... 
} 

Ora, io preferisco la seconda, ma con Java non ho bisogno tutto questo perché mentre io sono su un elemento che posso toglierlo e tuttavia la l'iterazione continuerà! Onestamente, anche se può sembrare fuori luogo, è davvero un'ottimizzazione in molti modi.