Это не актуальный вопрос программирования, мне просто нужен совет о том, как структурировать часть моей программы.
Программа разделена на клиентскую и серверную части. Оба разделяют определенный код, включая базовые классы. Вот представление кода, с которым у меня проблемы:
Общие классы:
class BaseEntity
{
public:
virtual void EmitSound(std::string snd) {}
virtual bool IsPlayer() {return false;}
};
class BasePlayer
: public BaseEntity
{
public:
bool IsPlayer() {return true;}
}
Серверные классы:
class Entity
: public BaseEntity
{
public:
void EmitSound(std::string snd)
{
// Serverside implementation
}
}
class Player
: public Entity,BasePlayer
{
public:
void Kick() {}
}
Клиентские классы:
class CEntity
: public BaseEntity
{
public:
void EmitSound(std::string snd)
{
// Clientside implementation
}
};
class CPlayer
: public CEntity,BasePlayer
{
public:
void SetFOV() {}
}
(Методы всего лишь примеры)
Класс «Player» должен наследовать всех членов от «Entity» и «BasePlayer». Однако это не работает, так как оба имеют один и тот же родительский класс (BaseEntity).
Конечно, я мог бы удалить наследование из BasePlayer, но потом я бы получил две функции IsPlayer, каждая из которых возвращала что-то свое.
Я также мог бы переместить все элементы из «BasePlayer» в «Player» и «CPlayer» соответственно, но это привело бы к избыточности, которой я хотел бы избежать, и я бы больше не мог использовать один указатель для объектов любого типа. класс, сохраняя доступ ко всем общим методам.
Мне не нравится ни одно из этих решений, но я не могу думать ни о чем другом.
Есть ли оптимальное решение этой проблемы?
самое простое решение, которое, как мне кажется, решило бы вашу конкретную проблему, состояло бы в том, чтобы класс BasePlayer не наследовал от класса BaseEntity.
класс Player получит характеристики класса BaseEntity, потому что он наследует от класса Entity, который наследует от класса BaseEntity, а класс CPlayer получит характеристики класса BaseEntity, потому что он наследует от класса CEntity, который наследует от класса BaseEntity.
Других решений пока нет …