doppelte Vererbung

KN4CK3R

Das ist natürlich nur ein Minimalbeispiel hier fürs Forum *Kopfschüttel*
Die Klassen heißen so weil es dabei um die SourceEngine geht. In meinem Projekt heißen die Klassen auch anders.
Wie man da den DoD vermeiden kann, war gerade meine Frage, falls du die bisherigen Posts nicht lesen wolltest...

greetz KN4CK3R

me_s

KN4CK3R schrieb:

Wie man da den DoD vermeiden kann, war gerade meine Frage...

aber es wäre besser, einen neuen Blickwinkel zu finden

z.B:

struct IShooter {

   virtual bool CanShoot () const = 0;
};

enum PlayerChar {
   LocalPlayerChar,
   SourcePlayerChar
};

struct IPlayer {
   virtual bool isValid () const =0;
   virtual IShooter * getShooter () =0;   
};

...

KN4CK3R

ich hab mir sowas ähnliches überlegt:

class IPlayer
{
public:
	virtual bool IsValid() = 0;
	virtual bool Equals(const IPlayer &player) = 0;
};

class ILocalPlayer : public IPlayer
{
public:
	virtual bool CanShoot() = 0;
};

class SourceLocalPlayer: public ILocalPlayer
{
public:
	SourceLocalPlayer(SourcePlayer &player)
		: player(player)
	{

	}

	virtual bool IsValid()
	{
		return player.IsValid();
	}

	virtual bool CanShoot()
	{
		return false;
	}

	virtual bool Equals(const IPlayer &player)
	{
		return this->player.Equals(player);
	}

private:
	SourcePlayer &player;
};

hier bekommt der LocalPlayer dann sein eigentliches Player Objekt im Konstruktor mit und ruft dann jeweils dessen Implementierung des Interfaces auf. Dadran stört mich aber etwas, dass die SourceLocalPlayer "is a" SourcePlayer Verbindung verloren geht und ich quasi alle Funktionsaufrufe weiterleite (solange sie gleich sind).

greetz KN4CK3R

me_s

class ILocalPlayer : public IPlayer
{
public:
virtual bool CanShoot() = 0;
};

class SourceLocalPlayer: public ILocalPlayer
{
public:
SourceLocalPlayer(SourcePlayer &player)
: player(player)

eigentlich sieht das nicht schön aus.. können Sie erzählen, welche Unterschiede es zwischen Player-Klassen gibt ? dann wird es leichter eine richtige Lösung zu finden..

KN4CK3R

wie gesagt gibt es die normalen Spieler, deren Hauptunterschied zum lokalen Spieler ihr Schreibschutz ist. Auf andere Spieler kann nur lesend zugegriffen werden. (GetName, GetHealth, GetOrigin, ...) Der lokale Spieler bietet die gleichen Methoden an (er ist ja auch einer der Spieler), bietet aber noch zusätzlich Methoden an, mit denen er verändert werden kann (SetAngles, Shoot, MoveForward, ...)

Also dachte ich eben an die von mir erstellen Interfaces

class IPlayer
{
public:
	GetName = 0;
	GetHealth = 0;
	GetOrigin = 0;
	...
};

class ILocalPlayer : public IPlayer //Vererbung weil ILocalPlayer ist ein IPlayer
{
public:
	SetAngles = 0;
	Shoot = 0;
	MoveForward = 0;
	...
};

class ConcretePlayer : public IPlayer //ist ein IPlayer
{
public:
	...IPlayer Methoden...
};

class ConcreteLocalPlayer : public ConcretePlayer, public ILocalPlayer //ist ein ConcretePlayer und ist ein ILocalPlayer => DoD
{
public:
	...ILocalPlayer Methoden...
	//sollte von ConcretePlayer erben, damit hier nicht noch alle IPlayer Methoden implementiert werden müssen
};

greetz KN4CK3R

me_s

KN4CK3R schrieb:

Also dachte ich eben an die von mir erstellen Interfaces

dieser Vorgang nimmt viel Mühe umsonst..

KN4CK3R schrieb:

wie gesagt, gibt es die normalen Spieler, deren Hauptunterschied zum lokalen Spieler ihr Schreibschutz ist. Auf andere Spieler kann nur lesend zugegriffen werden.

es darf mithilfe von zwei Funktionen gelöst werden : getPlayerInfo () und getPlayerInfoConst.. und keine unnötige Vererbung..

KN4CK3R

du meinst ILocalPlayer sollte gar nicht von IPlayer erben, sondern nur mit einer Methode einen IPlayer zurückgeben?

greetz KN4CK3R

me_s

KN4CK3R schrieb:

du meinst ILocalPlayer sollte gar nicht von IPlayer erben, sondern nur mit einer Methode einen IPlayer zurückgeben?

es kann sein.. um diese Frage zu beantwotrten, ist es mehr Information nötig, was diese Klasse darstellen.

KN4CK3R

mehr Informationen kann ich nicht geben, da die "Lese Daten aus" Funktionalität die Hauptaufgabe der Spielerklassen sind.

greetz KN4CK3R

me_s

nicht diese Information, sondern : was für eine Konzeption haben Sie ausgewählt, die die Local-, Source-, und LocalSourcePlayers fordert.. Ich kann mir nicht vorstellen wozu braucht man so was..

KN4CK3R

wie ich das ganze benutze, habe ich hier beschrieben:
http://www.c-plusplus.net/forum/p2210487#2210487

greetz KN4CK3R

me_s

KN4CK3R schrieb:

wie ich das ganze benutze, habe ich hier beschrieben:
http://www.c-plusplus.net/forum/p2210487#2210487

ich hab das gelesen.. aber kann ich mir ein klares Bild nicht vorstellen..
die wichtigsten Momente liegen doch im Hintergrund..

KN4CK3R schrieb:

Ich hab im Spiel mehrere Spieler, einer davon ist der lokale Spieler.

meinen Sie, ein Lokalplayer ist ein "Ich"-Player, also der Player, den ich steurn kann ? was ist dann LokalSourcePlayer ?!

KN4CK3R

genau, IPlayer sind alle Spieler und ILocalPlayer ist der eine Spieler, den ich selbst steuern kann. Aus diesem Grund ist er auch der einzige, den ich nicht nur auslesen kann. Source(Engine)LocalPlayer heißt meine Implementierung des ILocalPlayer-Interfaces für die Source Spieleengine.

greetz KN4CK3R

me_s

KN4CK3R schrieb:

genau, IPlayer sind alle Spieler und ILocalPlayer ist der eine Spieler, den ich selbst steuern kann.
greetz KN4CK3R

dann das vorgeschlagene Modell mit der Vererbung ist nicht richtig..
jetzt versuche ich es zu beschreiben..

KN4CK3R

welche Frage genau? Innerhalb der Schleife könnte ich zum Beispiel den Namen der Spieler auslesen und auf den Bildschirm schreiben...
Was für Informationen fehlen dir noch (die zur Lösung des Problems hier beitragen)?

greetz KN4CK3R

me_s

grübeln wir bisschen nach..
es gibt eine Welt - dieses Spiel.. jede Person/Charakter in der ist eine SpielFigur.. die SpielFigur erhält die Daten, die jeder lesen kann, aber nur SpielController kann schreiben.. Außerdem braucht man den Spieler, der eine (oder einige) SpielFigur steurn kann.. Jedoch kann ein Spieler die SpielFigurDaten nicht schreiben, stattdessen muss er darum SpielController "bitten"..
Daraus folgt :
Ihr "IPlayer" ist SpielFigur und "ILokalPlayer" ist "richtiger" Spieler .