Итерация над структурой уровня с использованием вложенных итераторов

Question

У меня есть следующая структура уровня XML. Список ящиков, каждый из которых содержит список ящиков.

<Boxes> 
    <Box id="0"> 
     <Drawers> 
      <Drawer id="0"/> 
      <Drawer id="1"/> 
      ... 
     </Drawers> 
    </Box> 
    <Box id="1"> 
... 
    </Box> 
</Boxes> 

Я разбор его с помощью StAX и экспонировал структуру через два Iterators:

1. BoxIterator implements Iterator<Box>, Iterable<Box>
2. Box implements Iterable<Drawer>
3. DrawerIterator implements Iterator<Drawer>

, то я могу сделать следующее:

BoxIterator boxList; 
for (Box box : boxList) { 
    for (Drawer drawer : box) { 
    drawer.getId() 
    } 
} 

Под капотом этих Iterators я использую StAX и оба из них обращается к тому же основному XMLStreamReader. Если я вызову BoxIterator.next(), это повлияет на результат, который будет возвращен при последующих вызовах DrawerIterator.next(), потому что курсор переместится в следующее окно.

Означает ли это расторжение договора с Iterator? Есть ли лучший способ итерации над структурой двух уровней, используя StAX?

Answer 1

Означает ли это расторжение договора Iterator?

No.

Java-Iterator накладывает два "контракты". Первым контрактом является сам интерфейс Java, который объявляет 3 метода: hasNext(), next() и remove(). Любой класс, который реализует этот интерфейс Iterator, должен определить эти методы.

Второй контракт определяет поведение Iterator:

hasNext() [...] возвращает истину, если итерации имеет больше элементов. [...] next() возвращает следующий элемент в итерации [и] выбрасывает NoSuchElementException, если итерация не имеет больше элементов.

В этом и весь контракт.

Это правда, что если базовый XMLStreamReader продвинут, он может испортить ваши BoxIterator и/или DrawerIterator. В противном случае вызов BoxIterator.next() и/или DrawerIterator.next() в неправильные моменты может испортить итерацию. Однако правильно использовал, например, в вашем примере кода выше, он работает правильно и значительно упрощает код. Вам просто нужно задокументировать правильное использование итераторов.

В качестве конкретного примера класс Scanner реализует Iterator<String>, и все же он имеет много и много других методов, которые продвигают базовый поток. Если бы существовал более сильный контракт, наложенный классом Iterator, тогда сам класс Scanner нарушил бы его.

---

Как Ivan указывает в комментариях, boxList не должно быть типа class BoxIterator implements Iterator<Box>, Iterable<Box>. Вы действительно должны иметь:

class BoxList implements Iterable<Box> { ... } 
class BoxIterator implements Iterator<Box> { ... } 

BoxList boxList = ...; 
for (Box box : boxList) { 
    for (Drawer drawer : box) { 
    drawer.getId() 
    } 
} 

Имея один класс реализовать оба Iterable и Iterator не является технически неправильным для случая использования, это может привести к путанице.

Рассмотрим этого кода в другом контексте:

List<Box> boxList = Arrays.asList(box1, box2, box3, box4); 
for(Box box : boxList) { 
    // Do something 
} 
for(Box box : boxList) { 
    // Do some more stuff 
} 

Здесь boxList.iterator() вызывается дважды, чтобы создать два отдельные Iterator<Box> экземпляров, для перебора списка ящиков дважды. Поскольку boxList можно повторить несколько раз, для каждой итерации требуется новый экземпляр итератора.

В коде:

BoxIterator boxList = new BoxIterator(xml_stream); 
for (Box box : boxList) { 
    for (Drawer drawer : box) { 
    drawer.getId(); 
    } 
} 

, потому что вы итерация над потоком, вы не можете (без перемотки потока или хранений извлеченных объектов) перебрать одни и те же узлы во второй раз. Второй класс/объект не нужен; тот же объект может выступать как Iterable, так и Iterator ..., который сохраняет вам один класс/объект.

Сказав это, преждевременная оптимизация является корнем всего зла. Экономия одного класса/объекта не стоит возможной путаницы; вы должны разделить BoxIterator на BoxList implements Iterable<Box> и BoxIterator implements Iterator<Box>.

Answer 2

Он имеет потенциал, чтобы разорвать контракт по той причине, что hasNext() может вернуться true, но next() может кинуть NoSuchElementException.

Договор hasNext() является:

Возвращает истину, если итерации имеет больше элементов. (Другими словами, возвращает истину, если в следующем() возвращает элемент, а не бросать исключение.)

Но может случиться так, что между вызовом hasNext() и next(), другой итератор мог бы переместил положение потока таким образом, что больше нет элементов.

Однако, поскольку вы использовали его (вложенный цикл), вы не столкнетесь с поломкой.

Если вам нужно передать итератор другому процессу, вы можете столкнуться с этим поломкой.

Answer 3

Это не выглядит, как она будет разорвать контракт при условии вы тщательно реализации/переопределение next() & hasNext() методы в BoxIterator & DrawerIterator путем внедрения Iterator интерфейса. Само собой разумеется, очевидным условием для ухода является то, что hasNext() должен вернуть true, если next() возвращает элемент и false, если next() предоставляет исключение.

Но то, что я не мог понять, почему вы сделали BoxIterator реализовать Iterable<Box>

BoxIterator implements Iterator<Box>, Iterable<Box> Поскольку переопределение iterator() метод из Iterable интерфейса для Box всегда будет возвращать экземпляр BoxIterator. Если у вас нет других целей, то нет цели инкапсуляции этой функции в BoxIterator.

Answer 4

Единственная проблема с вашей частью кода заключается в том, что BoxIterator реализует как Iterator, так и Iterable. Обычно Iterable объект возвращает новый stateful Iterator каждый раз, когда вызывается метод iterator(). Из-за этого не должно быть никаких помех между двумя итераторами, но вам понадобится объект состояния, чтобы правильно реализовать выход из внутреннего цикла (возможно, у вас уже есть это, но я должен упомянуть его для ясности).

1. Объект State будет действовать как прокси-сервер для анализатора с двумя методами popEvent и peekEvent. На иетерах peek проверит последнее событие, но не будет его использовать. поп, они будут использовать последнее событие.
2. BoxIterable#iterator() будет использовать StartElement (Boxes) и после этого вернуть итератор.
3. BoxIterator#hasNext() будет заглядывать в события и всплывать до тех пор, пока не будет получен StartElement или EndElement. Он будет возвращен true, только если был получен StartElement (Box).
4. BoxIterator#next() будет заглядывать в атрибуты событий до появления элемента StartElement или EndElement для инициализации объекта Box.
5. Box#iterator() будет использовать событие StartElement (Ящики), а затем вернуть DrawerIterator.
6. DrawerIterator#hasNext() будет заглядывать и запускаться до появления элемента StartElement или EndElement. Затем он вернет true, только если он был StartElement (Drawer)
7. DrawerIterator#next() будет потреблять события атрибута, пока не будет получен EndElement (Drawer).

Ваш код пользователя будет оставаться почти без изменений:

BoxIterable boxList; 
/* 
* boxList must be an BoxIterable, which on call to iterator() returns 
* new BoxIterator initialized with current state of STaX parser 
*/ 
for (Box box : boxList) { 
    /* 
    * on following line new iterator is created and initialized 
    * with current state of parser 
    */ 
    for (Drawer drawer : box) { 
    drawer.getId() 
    } 
}