Назначение интерфейса Iterable

Question

public interface Walkable {
    void walk();
}

class Animal implements Walkable{
    public void walk() {
        //defines some way to walk
    }
}

В вышеприведенном примере класс Animal говорит, что я могу ходить, и он определил, как он идет.

Точно так же, почему любое агрегация объектов не может реализовать интерфейс Iterator и подразумевать, что он Итерируемый.

class Employee{
    Iterator getEmployeeIterator(){
        return new EmployeeCollection();
    }
}

class EmployeeCollection implements Iterator{
    Employee []emp;
    public boolean hasNext() {
        //implementation
    }
    public Object next() {
        //implementation
    }

Для чего нужен интерфейс Итерируемый, который просто возвращает Итератор. Он также не принимает никаких добавок. Если для этого нужны какие-то аргументы, я могу предположить, что он может работать как фабрика, обеспечивающая различные типы итераторов

Является ли "обеспечение общего интерфейса" единственной целью Iterable?

Answer 1

почему нельзя агрегировать объекты, просто реализуйте интерфейс Iterator и подразумевайте, что он итерируемый

Итератор имеет состояние . Он должен знать, какие элементы итератор уже возвратил, какие элементы не вернули, и какой элемент будет возвращен следующим.

Если коллекция была самой итератором, а расширенная для l oop работала на итераторах, вы не сможете выполнить итерацию дважды, как показано ниже:

for (Employee employee: employeeCollection) {
    // do something
}
for (Employee employee: employeeCollection) {
    // do something else
}

Когда первый l oop завершится, это означает, что вы достигли конца итерации. Поэтому второй l oop не может выполнять итерации для других элементов.

Можно утверждать, что запуск l oop может каким-то образом неявно "сбросить" итератор обратно к началу. Невозможно сбросить итератор, но это все равно не решит проблему. Как будет работать вложенная итерация, скажем, вы ищете пару сотрудников с одинаковым днем ​​рождения?

for (Employee employee1: employeeCollection) {
    for (Employee employee2: employeeCollection) {
        // do something
    }
}

Если внутренний for-l oop и внешний for-l oop совместно используют итератор В любом случае, этот алгоритм не может создать все пары сотрудников.

Вам действительно нужен способ создания итератора fre sh, который не зависит от других итераторов, которые могут существовать. Это то, что дает интерфейс Iterable.

Answer 2

Я мог бы подумать об одной причине, также указанной в комментариях. Прежде всего, если вы реализуете Iterable и переопределяете метод forEach(), то вы можете перебирать структуры данных следующим образом:

for(int i : myDataStructure) {
    System.out.println(i);
}

Если реализовано правильно, он должен печатать все элементы в ваших данных структура. Для каждого цикла цикл проще, чем обычный, в том смысле, что разные структуры данных имеют разные способы итерации. Например, с LinkedList, если вы используете для l oop для итерации, это займет больше времени, так как вы всегда начинаете с головы и go до узла с этим индексом каждый раз. Циклы for-each экономят пространство и время в зависимости от структуры данных.