Может ли кто-нибудь пояснить какая от них практическая польза? Дело в том, что я
понимаю механизм их работы, но я не понимаю для чего они нужны и где их можно использовать.
Рассмотрим на примере:
class Animal
{
public:
Animal():itsAge(1) { cout << "Animal constructor...\n"; }
virtual ~Animal() { cout << "Animal destructor...\n"; }
virtual void Speak() const { cout << "Animal speak!\n"; }
protected:
int itsAge;
};
class Dog : public Animal
{
public:
Dog() { cout << "Dog constructor...\n"; }
virtual ~Dog() { cout << "Dog destructor...\n"; }
void Speak() const { cout << "Woof!\n"; }
void WagTail() { cout << "Wagging Tail...\n"; }
}
int main()
{
Animal *pDog = new Dog;
pDog->Speak();
return 0;
}
РЕЗУЛЬТАТ:
Animal constructor...
Dog constructor...
Woof!
Суть использования виртуальных функций в том, что при обращении к методу через указатель
будет вызываться именно тот вариант, который был объявлен как виртуальный в базовом
классе и переопределен в производном.
Но во-первых, с помощью указателя класса Animal *pDog, всё равно не получишь доступ
к методу WagTail() (махать хвостом), поскольку он не был определен в классе Animal.
А во-вторых, используя данный механизм придется расплатиться определенными издержками,
связанными с созданием v-таблицы (каждый элемент которой занимает ресурсы оперативной
памяти).
К тому же я не понимаю, зачем передавать указатель на объект производного класса,
когда ожидается указатель на объект базового класса?
Обе вышеуказанные проблемы можно было бы решить объявив методы и в базовом, и в производном
не виртуальными, а затем написать следующее:
Dog *pDog = new Dog;
вместо:
Animal *pDog = new Dog;
Где "профит"?
Ответы
Ответ 1
Рассмотрите классический пример с графическими формами.
Вы можете определить класс Shape, который содержит общие методы для всех геометрических
фигур, которые вы собираетесь использовать в своем приложении.
Этот класс определяет общий интерфейс для всех геометрических фигур.
И, допустим, у вас есть форма, на которой вы хотите разместить геометрические фигуры.
Форма заранее не знает, какие геометрические фигуры ей придется в себя включать. Она
относится к геометрическим фигурам, как к некоторым абстрактным объектам, которые наделены
некоторыми методами, которые форма может использовать, чтобы вывести эти фигуры на консоль.
Так как к форме можно добавить любое количество геометрических фигур разного вида,
то возникает вопрос, а как их в форме хранить? Если нет общего абстрактного представления
этих фигур, то их нельзя будет хранить в форме, так как нужен один определенный тип
для объектов, чтобы их всех можно было бы хранить в каком-нибудь одном контейнере и
не заботиться о том, что фигуры на самом деле различны.
Это легко сделать, если наследовать все фигуры от одного класса, как в данном случае
от класса Shape, и в этом классе определить виртуальные методы, с которыми форма может
работать не зависимо от того, с каким конкретным объектом форма имеет дело.
Ниже приведена простая демонстрационная программа, которая реализует описанные идеи.
Есть один класс Form , который хранит все геометрические фигуры (в данном случае
это объекты классов LeftTriangle, RightTriangle и Rectangle) в стандартном контейнере
std::vector, и который имеет метод display, позволяющий вывести все формы на консоль,
делегируя каждой фигуре процесс вывода самой себя.
// Shape.cpp: определяет точку входа для консольного приложения.
//
// #include "stdafx.h"
#include
#include
#include
#include
struct Point
{
int x;
int y;
};
class Shape
{
protected:
Point upper_left;
char pixel = '*';
public:
explicit Shape(Point p = { 0, 0 }) : upper_left(p)
{
}
virtual ~Shape() = default;
char set_pixel(char pixel)
{
char old_pixel = this->pixel;
this->pixel = pixel;
return old_pixel;
}
virtual std::ostream & draw(std::ostream &os = std::cout) const = 0;
Point move(int dx = 0, int dy = 0)
{
Point old_upper_left = this->upper_left;
this->upper_left.x += dx;
this->upper_left.y += dy;
if (this->upper_left.x < 0) this->upper_left.x = 0;
if (this->upper_left.y < 0) this->upper_left.y = 0;
return old_upper_left;
}
};
class Triangle : public Shape
{
protected:
unsigned int height;
public:
explicit Triangle(unsigned int height = 1) : height(height)
{
}
};
class LeftTriangle : public Triangle
{
public:
explicit LeftTriangle(unsigned int height = 1)
: Triangle(height)
{
}
std::ostream & draw(std::ostream &os = std::cout) const override
{
for (int i = 0; i < upper_left.y; i++) os << '\n';
for (unsigned int i = 0; i < height; i++)
{
os << std::setw( upper_left.x )
<< std::setfill( ' ' )
<< ""
<< std::setw(i + 2)
<< std::setfill(pixel) << '\n';
}
return os;
}
};
class RightTriangle : public Triangle
{
public:
explicit RightTriangle( unsigned int height = 1)
: Triangle( height)
{
}
std::ostream & draw(std::ostream &os = std::cout) const override
{
for (int i = 0; i < upper_left.y; i++) os << '\n';
for (unsigned int i = height; i != 0; i-- )
{
os << std::setw(upper_left.x + i - 1 )
<< std::setfill( ' ' ) << ""
<< std::setw( height - i + 2 )
<< std::setfill( pixel )
<< '\n';
}
return os;
}
};
class Rectangle : public Shape
{
protected:
unsigned int height;
unsigned int width;
public:
explicit Rectangle( unsigned int height = 1, unsigned int width = 1 )
: height(height), width( width )
{
}
std::ostream & draw(std::ostream &os = std::cout) const override
{
for (int i = 0; i < upper_left.y; i++) os << '\n';
for (unsigned int i = 0; i < height; i++)
{
os << std::setw(upper_left.x ) << std::setfill( ' ' ) << ""
<< std::setw( width + 1 ) << std::setfill(pixel)
<< '\n';
}
return os;
}
};
class Form
{
public:
Form() = default;
void add( Shape * &&shape )
{
shapes.push_back(std::unique_ptr( shape ));
}
std::ostream & display(std::ostream &os = std::cout) const
{
const int Step = 10;
int dx = 0;
for (auto &p : shapes)
{
p->move(dx);
p->draw(os) << std::endl;
dx += Step;
}
return os;
}
private:
std::vector> shapes;
};
int main()
{
Form form;
form.add(new RightTriangle(5));
form.add(new LeftTriangle(5));
form.add(new Rectangle(5, 5));
form.display();
return 0;
}
Вывод программы на консоль
*
**
***
****
*****
*
**
***
****
*****
*****
*****
*****
*****
*****
Виртуальные методы определяют общий интерфейс для всех производных классов, позволяя
им самим определять реализацию данного интерфейса. Чтобы можно было обращаться к объектам
производных классов, как к однотипным объектам, наделенных общими свойствами, их надо
привести к какому-то общему типу. Таким общем типом может быть один из общих базовых
классов этих объектов. Тем самым достигается полиморфизм, то есть объекты, выглядящие
как объекты одного типа, имеют множество форм поведения и представления.
Конечно каждый производный класс может дополнительно определять свои члены данных
и методы. Но в таком случае это то, что различает их от объектов других производных
классов.
Например, вы можете сказать, что каждая женщина и каждый мужчина, это человек. Но
вы не можете сказать, например, что каждый человек - это женщина, или каждый человек
- это мужчина. Если рассматривать женщин и мужчин как людей, то вы можете обращаться
к ним независимо от пола, посылая им, как говорят в ООП, различные сообщения. Например,
если вы - кондуктор в автобусе, то вы можете потребовать предъявить проездной билет.
Для вас женщины и мужчины в автобусе - это пассажиры, и они должны иметь общие свойства
такие, как наличие проездного билета. Для этого вы должны рассматривать мужчин и женщин
как объектов некоторого общего типа, в данном случае, как пассажиров. Тем не менее
мужчины и женщины как объекты своего индивидуального класса различаются. Например,
женщины могут рожать, а мужчины не могут (если только мужчин - это не женщина, формально
сменившая пол по документам).
Ответ 2
Я не буду расписывать преимущества для всяких собачек или геометрических фигур, я
выскажу одно банально звучащее соображение, но которое для моего понимания в свое время
многого значило.
Когда говорят, что наследование облегчает повторное использование кода, то - о каком
коде речь? О том, что производный класс использует код из базового класса? Отнюдь.
Такие вещи можно делать простыми вызовами функций.
Наследование дает возможность по-новому использовать уже написанный (а то и скомпилированный
в виде динамических библиотек) код.
Какая-нибудь f(Base*); используется заново без каких-либо изменений, работая с кодом,
который и близко не был написан, а может, и даже не проектировался, когда была написана
и скомпилирована эта f() - просто это код виртуальной функции в производном от Base класса.
Да, это в определенной степени аналог передачи в функции указателей на другие функции,
но только в очень определенной степени. А, кроме того, вопрос "зачем нужна передача
в функции других функций?", надеюсь, не вызывает у вас недоумения "где же профит?"
Ответ 3
Как известно, С++ является компилируемым статически типизированным языком, что означает
разрешимость типов во время компиляции, так вот механизм виртуальных методов расширяет
эту возможность для случая, когда программист хочет именно в run time определить тип
объекта, применяя, например, dynamic_cast который бы в случае с НЕ полиморным классом
не сработал бы, а выдал ошибку компиляции.
Где "профит"?
допустим есть такой код
struct SomeThing
{
virtual void someGenericOperation() { cout << "base generic operation" }
~SomeThing();
};
struct SomeThingConcrete : SomeThing
{
void someConcreteOperation() {}
void someGenericOperation() { cout << "override generic op" } // override
};
SomeThing* p_smth = ...;
И пускай у нас такая ситуация в которой мы хотим проверить, что p_smth указывает
на тип SomeThingConcrete чтобы была возможность вызывать методы специфические для SomeThingConcrete
тоесть - someConcreteOperation().
проверка осуществляется следующим образом
SomeThingConcrete* p_concrete = dynamic_cast(p_smth);
if (p_concrete != NULL)
{
p_concrete->someConcreteOperation();
}
else
{
// p_concrete does not point to SomeThingInterface
}
Тоесть если downcast к типу SomeThing сработал (условие p_concrete != NULL выполнилось),
значит, наше предположение потвердилось и p_smth действительно указывает на SomeThingConcrete,
в противном случае p_smth указывает на какой - то другой производный от SomeThing класс.
Кроме этого, не будь базовый класс полиморфный, получилась бы лапша лишнего кода,
например, если передать в функцию указатель на базовый void f(SomeThing*), то из-за
свойства статического связывания пришлось бы перегружать функцию f для SomeThingConcrete
и для каждого нового наследника от SomeThing - чтобы вызывалась именно переопределённая
в производном версия унаследованного метода.
Динамическое связывание, применяя встроенный механизм вызова виртуальных методов
избавило бы от подобных перегрузок вовсе - тоесть
void f(SomeThing* p_smth) // f is a single polymorphic function
{
p_smth->someGenericOperation();
{
int main()
{
SomeThing* p_smth = new SomeThing();
SomeThing* p_smthConcrete = new SomeThingConcrete();
f(p_smth); // base generic operation
f(p_smthConcrete); // override generic operation
}
