Блог

Цель абстрактного класса — не позволить разработчикам создать объект базового класса, а затем апкастировать его, AFAIK.

Теперь, даже если апкастинг не требуется, и я все еще использую его, оказывается ли это каким-то образом «невыгодным»?

Еще одно уточнение:
Из размышлений на C :

Часто при проектировании требуется, чтобы базовый класс представлял только интерфейс для своих производных классов. То есть вы не хотите, чтобы кто-либо на самом деле создавал объект базового класса, только для преобразования в него, чтобы можно было использовать его интерфейс. Это достигается путем придания этому классу абстрактного вида,

Под апкастингом я имел в виду: baseClass *obj = new derived ();

Апкастинг может быть невыгоден для неполиморфных классов. Например:

 class Fruit { ... };  // doesn't contain any virtual method
class Apple : public Fruit { ... };
class Blackberry : public Fruit { ... };
  

переместите его куда-нибудь,

 Fruit *p = new Apple;  // oops, information gone
  

Теперь вы никогда не узнаете (без какого-либо ручного механизма), что if *p является экземпляром Apple или a Blackberry .

[Обратите внимание, что dynamic_cast<> это недопустимо для неполиморфных классов.]

Абстрактные классы используются для выражения концепций, которые являются общими для набора (под-) классов, но для которых нецелесообразно создавать экземпляры.

Рассмотрим класс Animal . Не имеет смысла создавать экземпляр этого класса, потому что нет ничего, что было бы просто animal . Существуют утки, собаки и слоны, каждый из которых является подклассом animal. Формально объявив класс animal, вы можете уловить сходства всех типов animals, а сделав его абстрактным, вы можете выразить, что его нельзя создать.

Апкастинг необходим для использования полиморфизма в статически типизированных языках. Это, как указал @Jigar Joshi в комментарии, называется принципом подстановки Лискова.

Редактировать: Апкастинг не является недостатком. На самом деле, вы должны использовать его, когда это возможно, чтобы ваш код зависел от суперклассов (интерфейсов) вместо базовых классов (реализаций). Это позволяет вам позже переключать реализации без необходимости изменять свой код.

Апкастинг — это технический инструмент.

Как и любой инструмент, он полезен при правильном использовании и опасен / невыгоден при непоследовательном использовании.

Это может быть хорошо или плохо в зависимости от того, насколько «чистым» вы хотите, чтобы ваш код соответствовал данной парадигме программирования.

Итак, C не обязательно является «чистым ООП», не обязательно «чисто универсальным», не обязательно «чисто функциональным». И поскольку C является «прагматичным языком», это, в общем, не является преимуществом, заставляющим его соответствовать «одной-единственной парадигме».

Единственное, что можно сказать в технических терминах, это то, что,

• Производный класс — это базовый класс плюс нечто большее
• Обращение к производному через базовый указатель делает это «нечто большее» недоступным, если только в базе не существует механизма, позволяющего перейти в производную область.
• Механизм, который C предлагает для этого неявного перехода, — это виртуальные функции.
• Механизм, предлагаемый C для явного перехода, является dynamic_cast (используется при нисходящей передаче).
• Для неполиморфных объектов (у которых нет никакого виртуального метода) static_cast (для понижения) все еще доступен, но без проверки во время выполнения.

Преимущества и недостатки вытекают из последовательного и непоследовательного использования всех этих точек вместе. Это не вопрос, связанный только с downcast.

Одним из недостатков была бы очевидная потеря новой функциональности, введенной в производный класс:

 class A
{
   void foo();
}

class B : public A
{
   void foo2();
}

A* b = new B;
b->foo2(); //error - no longer visible
  

Я говорю здесь о невиртуальных функциях.

Кроме того, если вы забудете сделать свои деструкторы виртуальными, у вас могут возникнуть некоторые утечки памяти при удалении производного объекта через указатель на базовый объект.

Однако всего этого можно избежать при хорошей архитектуре.