Научить метод принимать в качестве аргумента объект своего класса и дочерних классов

Как научить метод принимать в качестве аргумента объект своего класса и дочерних классов? Как их передавать при вызове метода?

0

по ссылке, если это то, что я подумал.

0

Сообщение от shilko2013 public: Metod (Class & a);

Зачем & ?

0

Сообщение от JackLas Зачем & ?

Method (class & a) - это значит что вы передаете объект по ссылке и имеете дело с существующим объектом.
Mehod (class a) - будет сделана локальная копия объекта и её изменение не будет влиять на объект который был передан в этой функции.
А вообще наследники родительского класса приобретают все свойства и методы родительского класса. И объект производного класса можно смело передавать в метод который принимает ссылку на базовый класс.


Так же можно сделать метод виртуальным и переопределить его в наследниках. Он станет полиморфным при вызове через указатель базового класса. Вариантов много все зависит от того что конкретно надо

Добавлено через 14 минут

Сообщение от Anglues113 this->x = i;

В этом месте написать - и оно будет работать

0

Сообщение от JackLas Как научить метод принимать в качестве аргумента объект своего класса и дочерних классов? Как их передавать при вызове метода?

http://codepad.org/U55N0i2U

7parrent 6child1 6child2

0

Сообщение от Unknownx отличать классы

В нормальном режиме это и не требуется. Полиморфизм покрывает почти все кейсы.

0

0

Unknownx, в общем случае попытка выяснить тип объекта по ссылке на базовый класс говорит о каких-то проблемах в архитектуре. Идея полиморфизма заключается в том, что в наследниках класса находится код, который привязан к типу этого наследника и делает в соответствии со своим специфическим знанием что-то отличное от других наследников. При этом код, который использует указатель/ссылку на базовый класс должен работать с ним как с целостной сущностью и ни в коем случае НЕ должен начинать зависеть от того, какой на самом деле наследник базового класса был проброшен при вызове, а наследник должен реализовывать функциональность в соответсвии с заявленной в базовом классе (принцип подстановки Лисков (LSP из SOLID). Если говорить о некоторых более частных случаях, скажем в виде исключения - то может использоваться либо двойная диспетчеризация - когда с одной стороны используется полиморфизм для обработки вызова, с другой стороны вызываются разные перегрузки методов исходя из типа аргумента (Таким образом устроен boost::static_visitor для boost::variant). Наконец если используются техники типа type erasure и по какой-то причине понадобилось знать какой тип действительно находится за концепцией any/type_erasure/variant могут использоваться либо подходы с кастами ( в том числе специфические для данного типа, а не dynamic_cast, например как в any_cast). Ну и самый прямолобый вариант - просто иметь метод, который возвращает тип хранимого в базовом классе наследника (как например реализовано в QVariant::type). Если Вы приведете конкретный пример задачи, решение которой Вас интересует с точки зрения использования полиморфизма, мы могли бы подумать над тем, можно ли найти её решение без попыток выяснения типа наследника в пользователе базового класса.

0

Сообщение от Melg Unknownx, в общем случае попытка выяснить тип объекта по ссылке на базовый класс говорит о каких-то проблемах в архитектуре.

- глупость. Пример : я могу использовать кросс-платформенный фрейморк, в котором к примеру есть класс канвы привязанный к конкретной платформе, к примеру под маком будет макканва, под убунтой - убунтуканва, под вин винканва, каждая канва в силу различия плафторм имеет свои особенности при этом имеет общую сущность, мой рендерер должен распознать какая канва к нему пришла, а может и ноль прийти(или ты всё дефанами будешь разруливать делая спагетти код, м? Что по твоему лучше - 3 платформоспецифических канвы в разных либах или одна с 3 типами #ifdef). Думаю ты просто привык максим к виртуальным методам, а я привык работать без КуТэ сразу под несколькими осями, так что надеюсь понятно почему я написал глупость на твои слова.

0

Unknownx, Не смотря на Ваш, мягко говоря, своеобразный способ общения, мне было бы интересно узнать действительно ли Ваше положение не удастся спасти никак кроме как через выяснение типа наследника. Вы можете привести минимальный пример кода, который бы воспроизводил ситуацию? (Вот с теми же канвами) потому-что из Ваших слов мне не понятно о каких "особенностях" в канвах идет речь, и как они при этом используются в рендере. (Если у вас есть opensource проект иллюстрирующий проблему - я могу взглянуть и на него).

0

0

0

0

Сообщение от Melg Unknownx, Не смотря на Ваш, мягко говоря, своеобразный способ общения, мне было бы интересно узнать действительно ли Ваше положение не удастся спасти никак кроме как через выяснение типа наследника.

Судя по упоминанию ifdef и дефайнов, у него там условная компиляция, а не выяснение типа объекта на стадии исполнения.

0

Сообщение от Unknownx - глупость. Пример : я могу использовать кросс-платформенный фрейморк, в котором к примеру есть класс канвы привязанный к конкретной платформе, к примеру под маком будет макканва, под убунтой - убунтуканва, под вин винканва, каждая канва в силу различия плафторм имеет свои особенности при этом имеет общую сущность, мой рендерер должен распознать какая канва к нему пришла, а может и ноль прийти(или ты всё дефанами будешь разруливать делая спагетти код, м? Что по твоему лучше - 3 платформоспецифических канвы в разных либах или одна с 3 типами #ifdef). Думаю ты просто привык максим к виртуальным методам, а я привык работать без КуТэ сразу под несколькими осями, так что надеюсь понятно почему я написал глупость на твои слова.

У нас будет свой фреймворк! С полиморфизмом и абстракциями! И, таки, навелосипедили. Только с абстракциями косячок вышел: оказались очень страшными, поэтому все чаще приходится заниматься полиморфизмом в клиентском коде, аж руки стерли. Сопровождается использованием dynamic_cast вместо виртуальных методов. И еще что-то говорят про спагетти код.

0