По-моему они только вносят путаницу. Я так понял их роли: Iterable говорит что по объектам класса в принципе можно итерироваться, а Iterator задает сами методы для итерирования. Но по-моему все это отлично смотрелось бы в одном интерфейсе. Который и объявлял бы класс итерируемым и одновременно задавал бы методы для итерирования.
Можно было бы об этом задуматься, если предполагаемое соответствие Iterable
и его Iterator
было "один к одному". Но дело обстоит иначе: Iterable
может в некий момент обходиться несколькими Iterator
сразу (возможно, ещё и в разных thread'ах!). То есть, это интерфейсы, представляющие две разных сущности: коллекцию и обход коллекции.
Уже поэтому стоит их разделить, поскольку в противном случае для нескольких параллельных обходов коллекция должна быть всегда завёрнута в итератор и иметь два вида копирования (для итератора и для коллекции), а тут уже просматривается явное нарушение SRP (Single Responsibility Principle, принципа единственной обязанности).
Оборудование для ресторана: новинки профессиональной кухонной техники
Частный дом престарелых в Киеве: комфорт, забота и профессиональный уход
Есть конструктор с параметрами, к примеру: конструктор(параметр1, параметр2); Хочу предотвратить получение в качестве аргумента к параметру2...
Зачем нужна коллекция Stack, она расширяет Vector, который и так уже медленный из-за синхронизацииА в чем прикладной смысл этого Stack?
Есть некое клиент-серверное десктопное приложение, отправлять запросы и получать их оно будет только тогда, когда запущено, а следственно,...