Как разрешить использование только конкретного наследуемого от интерфейса, не финального класса?

Question

[rusyska55011]

Предположим, есть Иерархия классов A -> B -> C. И еще есть класс Y.

Конструктор класса Y принимает тип данных B, то есть экземпляр его класса => Отсюда и вопрос: "Как мне исключить ввода объектов экземпляра класса С? Чтобы в него вбивался исключительно B!"

Comments

[mayton2019]

Обычно когда приходил человек и хочет чего-то "эдакого..." к нему возникают вопросы.

Чем продиктован запрет использования ООП в твоём случае? Ты сломал принцип старухи Лисков?

[rusyska55011]

mayton2019, при изучении языка у меня возник такой вопрос, чисто теоретически. Вот мой пример:

class Gun {
    public:
        virtual void shoot() {
            cout << "POOF";
        }
};

class MultiGun : public Gun {
    public:
        void shoot() override {
            for (int i = 0; i < 10; i++)
                cout << " POOF ";
            cout << "\n";
        }
};

class SuperMultiGun : public MultiGun {
    public:
        void shoot() override {
            for (int i = 0; i < 30; i++)
                cout << " POOF ";
            cout << "\n";
        }
};

class Player {
    public:
        Gun *gun;

        Player(Gun* gun) : gun(gun) {}

        virtual void change_gun(Gun* gun) {
            this->gun = gun;
        }

        void shoot() const {
            this->gun->shoot();
        }
};

class OnlyMultiGunPlayer : public Player {
    public:
        MultiGun* gun;

        OnlyMultiGunPlayer(MultiGun *gun) : gun(gun), Player(gun) {}
};

Хочу чтобы OnlyMultiGunPlayer мог иметь только объект MultiGun, а так я в него могу и SuperMultiGun запихнуть)

[Adamos]

rusyska55011, с опытом это пройдет. Почитайте пока про SOLID, раз уж вас в них ткнули носом.
Это в любом случае полезно.

[rusyska55011]

Adamos, я знаю про солид, но для общего понимания хочу знать как это реализовать

[Adamos]

rusyska55011, это нет смысла реализовать, это выкидыш недостатка понимания.
Постановка задачи - вообще не на том уровне логики, на котором она должна решаться.
Отношения классов - это вотчина и ограничения программиста, нечего в них даже лезть с логикой приложения.

[Евгений Шатунов]

rusyska55011, решишь задачу правильно, отвечу на твой вопрос.

Для решения задачи у тебя есть два множества: множество "A" и множество "B". И есть интерфейс с функцией "virtual B Intf::Foo(A) = 0";
В базе кода уже присутствует полсотни имплементаций этого интерфейса и больше тысячи мест использования имплементаций по интерфейсу.
Твоя задача - создать еще одну имплементацию "Intf::Foo", для работы которой потребуется сперва как-то изменить как множество "A", так и множество "B".
Вопрос: какие ограничения уже имеющийся код накладывает на твои возможности по изменению множеств "A" и "B"?

[Дмитрий]

rusyska55011, для вашего примера ООП не годится. Используйте Entity Component System.

Answer 1

[Wataru]

Практически никак. Суть полиморфизма в том, что экземпляры наследников можно вставлять вместо экземпляра предка везде и все будет работать. Поэтому вы средствами языка никак не запретите передавать C вместо B (речь об указателях, естественно). Если хочется, то можно сделать виртуальную функцию, которая возвращала бы какое-то enum, для идентификации классов A,B,C (и других наследников) и уже в функции проверять, что там не передали по ошибке экземпляр C. Но логичнее было бы выделить каие-то свойства у классов (например, количество пуль в вашем примере с MultiGun) их задать в виртуальных функциях у всех классов и дальше в функции проверять, что переданный экземпляр обладает нужными свойствами. Жестко привязываться, что можно B, но нельзя C - это плохой подход. Почему нельзя? А если потом появится D,E,F - можно ли их передавать? А если они братья B?