Архитектура движка.Статьи

Паттерны GoF - Iterator (лекция)

Автор:

<MiF> Iterator
<MiF> Назначение - предоставление последовательного доступа к
  элементам составного объекта, не раскрывая его структуры
<MiF> Применяется когда: :)
<MiF> 1. нужен доступ к содержимому агрегированных объектов,
  без раскрытия их внутреннего строения
<MiF> 2. нужно предоставить единообразный интерфейси обхода
<MiF> *интерфейс
<MiF> Участники:
<MiF> 1. Iterator - интерфейс для доступа и обхода элементов
<MiF> 2. ConcreteIterator - реализация, хранит все что нужно
  для обхода
<MiF> 3. Aggregate - определяет интерфейс для создания
  итератора
<MiF> 4. ConcreteAggregate - реализует интерфейс Aggregate,
  возвращает нужного ConcreteIterator'а
<MiF> Что это дает:
<MiF> 1. можно спокойно поддерживать разные способы обхода
  сложных агрегатов
<MiF> 2. интерфейс агрегата упрощается, то есть все для обхода
  уходит в интерфейс итератора
<MiF> Хай Zeux
<MiF> Кому-нибудь нужен пример реализации?
<MiF> Или итак все ясно?
<dRake> :)
<MiF> Не страшно
<MiF> :)(
<MiF> :)
<dRake> ну поидее ясно %)
<Zeux> про что уже было?
<MiF> это первое
<MiF> <CEMEH> Хочется пример итератора, хоть немного
  отличающегося от STL
<MiF> сейчас рожу какой-нибудь абстрактный пример
<Zeux> это
<Zeux> вот пусть есть dxt-изображение
<Zeux> и нужно его распаковать
<Zeux> пишется итератор, который возвращает блок 4x4
<Zeux> и у которого есть ++
<cppguru> а в чем отличиет от stl?
<cppguru> вообще, хочется пример полиморфных итераторов
<MiF> cppguru, я пишу
<cppguru> ок
<Zeux> в том, что в STL тупые итераторы
<Zeux> которые, собственно, только итерируются, не содержа в
  себе ничего полезного
<cppguru> вот например istream_iterator делает кучу полезного
  в operator*()
<MiF> -m
<CEMEH> В общем, вопрос заключается в показе разнообразия
  итераторов.
<CEMEH> В STL есть два примера - 1) указатель на нод
  контейнера и сложная логика перехода
<CEMEH> и 2) stream_iterator
<CEMEH> Хочется еще.
<CEMEH> Пример Zeux'a иллюстрирует unpack on demand, как я
  понимаю.
<Zeux> да
<MiF> http://www.everfall.com/paste/id.php?z4jpbc0kbzj8
<MiF> абстрактный пример
<MiF> ;)
<ZeroNET> 9 минут осталось до выхода
<MiF> вообщем могут быть полезны абстрактные итераторы, если
  есть семейство сложных составных объектов, с разной
  структурой, которые нужно обходить одинаково
<CEMEH> Отлично. Жизненный пример с такими итераторами?
<MiF> Думаю :)
<cppguru> обычные итераторы, только runtime полиморфизм вместо
  compile-time
<cppguru> что лучше - ещё вопрос
<MiF> cppguru, ну да
<CEMEH> Для каких структур нужен runtime-полиморфизм
  итераторов?
<CEMEH> И вообще нужен полиморфизм?
<CEMEH> Думаю, с разрешения аффтара на вопросы могут отвечать
  и другие.
<MiF> все могут отвечать
<MiF> я лишь рассказчик
<MiF> :)
<cppguru> ну, может захотеться динамически плодить и
  коллекции, и их итераторы соответственно
<CEMEH> Я могу сам ответить. Например, фильтры.
<ZeroNET> а потом это в спор перерастет и будет бардак
<MiF> +m спасет
<ZeroNET> точно
<CEMEH> Ладно. Если ни у кого нет жизненных и ярких примеров
  таких итераторов, продолжим.

21 января 2006