количество очков

Ну это как бы на корню же убивает полиморфизп и в целом ООП?

ооп ради ооп?

так если честно, я так и делаю в С++

полиморфизм про поведение, а не про "кол-во очков"

Ну с очками немного глуповато вышло - да, их проще просто хранить в переменной. Это правда.

было бы интересно взлянуть на 2 класса наследника. судя по тому, что их прям дофига - разница должна быть невелика... вот в чем она?

На самом деле - это надуманный пример. Тут будет два наследника все верно, brick - scor brick. Немного мой косяк, я хотел придумать какую-то штуку для себя и найти ее решение. Но у меня есть реальный пример, в котором я ничего не понимаю. Могу задать вопрос?

стоит выделить интерфейс и несколько реализаций. интерфейс в с++ - это класс только с чистыми виртуальными функциями. глубину наследования ограничить 1м уровнем. и многое встанет на свои места

да задавай конечно)

интерфейс кирпичика, классы типов кирпичиков, очки в классах

а не лучше один класс кирпичика, и сделать его data driven, чтобы грузил количество очков за себя из файла, основываясь на типе кирпичика, который он получает в конструкторе?

Смотри:

Поймешь код?

#include <cstdint>
#include <memory>

class render_data_base_t
{

};

class render_data_rectangle_t : public render_data_base_t
{
public:
    void set_w( uint32_t w )
    {

    }

    void set_w( uint32_t w )
    {

    }
};

class render_data_circle_t    : public render_data_base_t
{
public:
    void set_r( uint32_t )
    {

    }
};

class interface_get_render_data_t
{
public:
    virtual render_data_base_t* get_render_data()                       = 0;
};

class interface_set_render_data_t
{
public:
    virtual void                set_render_data( render_data_base_t* )  = 0;
};

class render_object_base_t : public interface_get_render_data_t,
                             public interface_set_render_data_t
{
    std::unique_ptr<render_data_base_t>    m_render_data;
public:
    virtual render_data_base_t* get_render_data()                       override
    {

    }

    virtual void                set_render_data( render_data_base_t* )  override
    {

    }
};

А теперь вопрос такой, хочу я где-то, получать мои рендер данные и гарантированно известно, что там это всегда render_data_circle_t - дочерний класс, и вот хочется мне у него менять радиус, а я получаюбазовый класс. Кажется, что самое место двойной диспетчеризации и Visitor паттерну, у которого, правда что, для прямоугольника - будет пустой метод, а вот для круга - нужное поведение. И вот это -смущает. Вдумавшись, я вижу тут ошибку проектирования иерархии, и вот, уже кажется что нужен не только render_object_base_t, который полиморфно принимает что угодно, но и render_circle_object_base_t. Вот как сделать? Мне важно как правильно, а не как гибко или быстро и т.п

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

Ты про какой пустой класс именно?

Здесь чисто набросок

Он как минимум виртуальный деструктор содержать будет

возможно у тебя нужен дженерик

опиши задачу словесно лучше.

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