Perdoe-me se não estou entendendo o que você quer, mas parece que você está combinando os conceitos de Iterator e Factory / Builder.
Deixe-me fazer algumas considerações aqui.
O padrão Iterator funciona bem para uma coleção homogênea de objetos que você deseja distribuir por meio de uma interface comum. Por exemplo, você tem uma coleção de Strings e quer que elas sejam distribuídas em uma ordem específica para que você use um Comparator (nos bastidores) e seu código consumidor só precise chamar next () algumas vezes para atingir seu objetivo.
O padrão Fábrica cria uma instância de um Objeto de acordo com uma determinada especificação - algumas vezes fornecida como argumentos, algumas vezes inferida. O padrão do Construtor é semelhante, mas geralmente é voltado para a conclusão de uma única etapa no caminho até a conclusão de uma instância de uma coleção composta de Objetos.
Parece a partir do seu exemplo de código que você deseja um mecanismo que permita criar uma instância de um objeto (de tipo variável) em resposta a um determinado número de chamadas. Talvez uma sequência como esta:
next() -> getType1() -> String with "Hello"
next() -> getType2() -> Integer with 4
next() -> getTypeN() -> some function applied -> some type returned
e assim por diante.
Se é isso que você procura, essa abordagem viola o Princípio da menor surpresa. Como desenvolvedor, se um objeto estiver sendo silenciosamente mutado nos bastidores, eu gostaria de saber sobre ele, pois quero conhecer os problemas de encadeamento e desempenho que podem surgir.
Como o problema que parece enfrentar é manter uma coleção de objetos entre chamadas da Web sem estado, é melhor usar uma Lista simples e fornecer o índice para a entrada atual como parte da resposta ao cliente. Quando o cliente solicitar o conteúdo da Lista, simplesmente o entregue ao JAXB para empacotá-lo em XML / JSON (ele usará um Iterator).
Essa abordagem mantém seu código simples e, portanto, impede os desenvolvedores depois de você olhar o código e dizer WTF?