Qual é a melhor abordagem para ter algum tipo de iterador preguiçoso, onde o retorno é avaliada apenas a pedido?

Question

import java.util.Collection;

import example.Event;

public interface Query
{
    public boolean hasMore ();

    public Collection<Event> getNext ( long count ) throws Exception;
}

Esta é a interface que eu tenho, o que eu quero implementar.

A implementação é suposto ser assim:

import java.util.ArrayList;
import java.util.Collection;
import java.util.Iterator;
import java.util.List;

import example.Event;
import example.Query;

public class ListQuery implements Query {

    public ListQuery(List<Event> events, String filter)
            throws FilterParseException {
        // events is the list of given events
        // filter is a string representation of the filter to apply
    }

    public Collection<Event> getNext(long count) throws Exception {
         // returns max. count next entries which match given filter
    }

    public boolean hasMore() {
        // returns if there are more elements matching the given filter
    }
}

O que eu estou pensando, é a relação entre hasMore () e getNext (). Em ambos os casos eu tenho que avaliar se o filtro corresponde um elemento da lista. Possivelmente eu não sei a implementação da lista dada, assim que poderia ser uma operação cara. Obviamente eu não posso usar apenas hasNext () de um iterador, porque eu tenho que verificar se o evento corresponde aos critérios fornecidos. Na minha implementação atual Eu tenho dois iteradores diferentes e a posição atual, onde o um para hasMore () é movido para cima se a posição do iterador para getNext () é maior do que o outro para hasMore ().

O que eu realmente gostaria de fazer, é clonar o iterador atual, que eu por sua vez usaria para hasMore (), mas isso não é possível, obviamente.

Existe uma solução mais elegante para este problema?

Answer 1

Na sua implementação getNext, depois de atribuir o valor de retorno, você poderia avançar sua iterador até encontrar um evento apropriado. Desta forma, seu hasMore pode seguramente hasNext teste em seu iterador para determinar se deve true retorno ou false.

Answer 2

Pare de se torturar :-) e usar apenas isto:

Iterables.filter (Iterable, predicado)

Ela cuida desses problemas para você.

Se você não tem seus dados em qualquer coisa Iterable apenas um Repetidor, consulte os Iterators classe correspondente. Se você precisa implementar o Iterator si mesmo, pode ajudar a prolongar AbstractIterator no mesmo pacote.

Então, se você realmente quer ser capaz de recuperar pedaços de resultados você pode usar o método de partição () das classes Itera * s.

Answer 3

Eu estou pensando que você não precisa mesmo de dois iteradores. A chamada hasMore pode iterar todo o caminho até encontrar um jogo e só ficar lá (se o elemento que já aponta para jogos, não iterate). Agora o getNext vai usar mesmo iterador para iterar e coleta de retorno populate até que a contagem seja atingido ou não mais elementos correspondentes são encontrados.