Частные копии коллекций
Если итератор и его курсор не позволяют вносить изменения в коллекцию, существует простой выход: создать частную копию коллекции в конструкторе итератора. На псевдокоде это выглядит так:
class Iterator {
private:
Collection collection;
Cursor location; // Текущая позиция в копии
public:
Iterator(Collection& c)
: collection(c), location(collection.First()) {}
bool More();
Foo* Next();
};
Конструктор итератора с помощью конструктора копий класса Collection создает вторую частную копию коллекции. Перед вами - один из редких случаев, когда действительно имеет значение тот факт, что переменные класса конструируются в порядке их перечисления; объект collection должен быть сконструирован раньше объекта location, в противном случае вам предстоят мучения с отладкой функции First().
Коллекции объектов или коллекции указателей?
Эта схема обычно используется в ситуациях, когда коллекция состоит из указателей или ссылок на объекты, которые во всем остальном никак не связаны с коллекцией. В других коллекциях вместо указателей или ссылок содержатся собственно объекты.
template <class Type, int Size>
class Array {
private:
int Size; // Количество объектов Type
Type elements[size]; // Объекты (внутренние)
// и т.д.
};
Здесь объекты буквально внедряются в коллекцию. Чтобы продублировать коллекцию, вам придется скопировать не только указатели, но и объекты - а это может обойтись слишком дорого. С другой стороны, может возникнуть необходимость в том, чтобы итератор возвращал указатель или ссылку на исходный объект исходной коллекции, а не на копию. В любом случае вариант с частными коллекциями отпадает.
Тот же принцип действует каждый раз, когда коллекция представляет собой набор ведущих указателей на ее содержимое. Да, она содержит указатели, а не объекты, однако коллекция имеет право удалять эти объекты, поэтому частная копия будет неустойчивой. Некоторые вопросы управления памятью, связанные с этой проблемой - конкретнее, сборка мусора - рассматриваются в части 4 этой книги.
Упрощение частной коллекции
Предположим, исходная коллекция представляет собой бинарное дерево или другую сложную структуру данных. Так ли необходимо воспроизводить в копии все дополнительные издержки древовидной структуры, если учесть, что вы не собираетесь пользоваться индексированным доступом?
Существует общепринятое решение - создать в качестве частной копии упрощенный вариант коллекции. Это будет проще, если в классе коллекции имеется оператор преобразования, порождающий экземпляр упрощенной коллекции. Вместо конструктора копий коллекции итератор использует ее оператор преобразования:
class SimpleCollection; // Упрощенный вариант
class ComplexCollection {
public:
operator SimpleCollection*();
};
Существует и другой, похожий вариант - создать в классе SimpleCollection конструкторы для всех остальных типов коллекций. Однако с точки зрения дизайна такое решение неудачно - каждый раз, когда вы придумаете какую-нибудь новую экзотическую коллекцию, вам придется изменять класс SimpleCollection. Для таких случаев существуют операторы преобразования.
Если использовать этот вариант, итератор становится универсальным и подходящим для различных типов коллекций. Итератору не нужно ничего знать об исходной коллекции. Конструктору итератора передается адрес упрощенной коллекции вместо исходной, при этом интерфейс выглядит так:
class Iterator {
private:
SimpleCollection* collection;
Cursor location; // Текущая позиция в копии
public:
Iterator(SimpleCollection* c)
: collection(c), location(collection->First()) {}
bool More();
bool Next();
};