Shape* p1 = new Rectangle(Point(0,0),Point(10,20));
better(make_ref(s0)); // ошибка: требуется Array_ref<Shape>
better(make_ref(s1)); // ошибка: требуется Array_ref<Shape>
better(make_ref(s2)); // OK (преобразование не требуется)
better(make_ref(p1,1)); // OK: один элемент
delete p1;
p1 = 0;
better(make_ref(p1,1)); // OK: нет элементов
better(make_ref(q,max)); // OK (если
переменная max задана корректно)
}
Мы видим улучшения.
• Код стал проще. Программисту редко приходится заботиться о размерах объектов, но когда это приходится делать, они задаются в специальном месте (при создании объекта класса
Array_ref
), а не в разных местах программы.
• Проблема с типами, связанная с преобразованиями
Circle[]
в
Shape[]
и
Polygon[]
, и
Shape[]
, решена.
• Проблемы с неправильным количеством элементов объектов
s1
и
s2
решаются неявно.
• Потенциальная проблема с переменной max (и другими счетчиками элементов, необходимыми для использования указателей) становится явной — это единственное место, где мы должны явно указать размер.
• Использование нулевых указателей и пустых векторов предотвращается неявно и систематически.
25.4.4. Наследование и контейнеры
Что делать, если мы хотим обрабатывать коллекцию объектов класса
Circle
как коллекцию класса
Shape
, т.е. если действительно хотим, чтобы функция
better
(представляющая собой вариант нашей старой знакомой функции
draw_all
; см. разделы 19.3.2 и 22.1.3) реализовала полиморфизм? По существу, мы не можем этого сделать. В разделах 19.3.3 и 25.4.2 показано, что система типов имеет веские основания отказаться воспринимать тип
vector<Circle>
как
vector<Shape>
. По той же причине она отказывается принимать тип
Array_ref<Circle>
как
Array_ref<Shape>
. Если вы не помните, почему, то перечитайте раздел 19.3.3, поскольку данный момент очень важен, даже если это кажется неудобным.
Более того, для того чтобы сохранить динамический полиморфизм, мы должны манипулировать нашими полиморфными объектами с помощью указателей (или ссылок): точка в выражении
a[i].draw
в функции
better
противоречит этому требованию. Когда мы видим в этом выражении точку, а не стрелку (
–>
), следует ожидать проблем с полиморфизмом
Что нам делать? Во-первых, мы должны работать с указателями (или ссылками), а не с самими объектами, поэтому следует попытаться использовать классы
Array_ref<Circle*>
,
Array_ref<Shape*>
и тому подобные, а не
Array_ref<Circle>
,
Array_ref<Shape>
и т.п.
Однако мы по-прежнему не можем конвертировать класс
Array_ref<Circle*>
в класс
Array_ref<Shape*>
, поскольку нам потом может потребоваться поместить в контейнер
Array_ref<Shape*>
элементы, которые не имеют типа
Circle*
. Правда, существует одна лазейка.
• Мы не хотим модифицировать наш объект класса
Array_ref<Shape*>
; мы просто хотим рисовать объекты класса
Shape
! Это интересный и совершенно особый случай: наш аргумент против преобразования типа
Array_ref<Circle*>
в
Array_ref<Shape*>
не относится к ситуациям, в которых мы не хотим модифицировать класс
Array_ref<Shape*>
.
• Все массивы указателей имеют одну и ту же схему (независимо от объектов, на которые они ссылаются), поэтому нас не должна волновать проблема, упомянутая в разделе 25.4.2.
Иначе говоря, не произойдет ничего плохого, если объект класса
Array_ref<Circle*>
будет интерпретироваться как неизменяемый объект класса
Array_ref<Shape*>
. Итак, нам достаточно просто найти способ это сделать. Рассмотрим пример < image l:href="#"/>
Нет никаких логических препятствий интерпретировать данный массив указателей типа
Circle*
как неизменяемый массив указателей типа
Shape*
(из контейнера
Array_ref
).
Похоже, что мы забрели на территорию экспертов. Эта проблема очень сложная, и ее невозможно устранить с помощью рассмотренных ранее средств. Однако, устранив ее, мы можем предложить почти идеальную альтернативу дисфункциональному, но все еще весьма популярному интерфейсу (указатель плюс количество элементов; см. раздел 25.4.2). Пожалуйста, запомните: никогда не заходите на территорию экспертов, просто чтобы продемонстрировать, какой вы умный. В большинстве случаев намного лучше найти библиотеку, которую некие эксперты уже спроектировали, реализовали и протестировали для вас. Во-первых, мы переделаем функцию
better
так, чтобы она использовала указатели и гарантировала, что мы ничего не напутаем с аргументами контейнера.
void better2(const Array_ref<Shape*const> a)
{
for (int i = 0; i<a.size; ++i)
if (a[i])
a[i]–>draw;
}
Теперь мы работаем с указателями, поэтому должны предусмотреть проверку нулевого показателя. Для того чтобы гарантировать, что функция
better2
не модифицирует наш массив и векторы находятся под защитой контейнера
Array_ref
, мы добавили несколько квалификаторов
const
. Первый квалификатор
const
гарантирует, что мы не применим к объекту класса
Array_ref
модифицирующие операции, такие как
assign
и
reset
. Второй квалификатор
const
размещен после звездочки (
*
). Это значит, что мы хотим иметь константный указатель (а не указатель на константы); иначе говоря, мы не хотим модифицировать указатели на элементы, даже если у нас есть операции, позволяющие это сделать.
Далее, мы должны устранить главную проблему: как выразить идею, что объект класса