3. Frage zu Mehrfachvererbung

Frage zu Mehrfachvererbung

  • ?

    Ich hab schon mehrmals gehört, dass man mit Mehrfachvererbung äusserst vorsichtig umgehen soll. Weis aber nicht genau wieso das so sein soll 😕

    Jedenfals wollt ich Fragen ob ich im folgenden Fall Mehrfachvererbung nehmen soll oder nicht.

    Es geht um ein Spiel, da habe ich einen Raum in dem eine Vielzahl von verschieden Objekten sein können, also mache ich eine Klasse Raum mit einem vector aus Pointern zu ObjektBasis. All Objekte leite ich nun von ObjektBasis ab.

    Einige Objekte können aber mit anderen zusammen stoßen, also muss ich auf Kollision test. Dadurch wird aber Raum und ObjektBasis ein Stück größer, also wollte ich eine weiter Klasse KollisionsRaum und eine weiter Klasse HartesObjektBasis. Objekte die zusammen stoßen können lasse ich von ObjektBasis und HartesObjektBasis erben und trage sie in Raum und KollisionsRaum ein.

    Ist das gut so oder habe ich den Zweck von Mehrfachvererbung nicht verstanden?

    0
  • V

    Irgendwer schrieb:

    Ich hab schon mehrmals gehört, dass man mit Mehrfachvererbung äusserst vorsichtig umgehen soll. Weis aber nicht genau wieso das so sein soll 😕

    weils undurchsichtig und kompliziert wird. doch erlebe es selbst!

    Jedenfals wollt ich Fragen ob ich im folgenden Fall Mehrfachvererbung nehmen soll oder nicht.

    erstens wirst du so lange mit dem gedanken spielen, bis du's doch gemacht hast, egal, was wir sagen...
    und zweitens mußt du selber spüren, wie sich der code anfühlt.
    ungefähr so: er wird total klasse sein, richtig elegant und so. fast kein if mehr (und switch eh nicht). alle wichtigen entscheidungen bestimmt der typ. ein wenig namensverwirrung beim auflösen des double dispatching probems mit dem hin-her-spiel. aber auch starr und unflexibel, schwer änderbar, festgefahren.

    Es geht um ein Spiel, da habe ich einen Raum in dem eine Vielzahl von verschieden Objekten sein können, also mache ich eine Klasse Raum mit einem vector aus Pointern zu ObjektBasis. All Objekte leite ich nun von ObjektBasis ab.

    soweit alles klar.

    Einige Objekte können aber mit anderen zusammen stoßen, also muss ich auf Kollision test. Dadurch wird aber Raum und ObjektBasis ein Stück größer, also wollte ich eine weiter Klasse KollisionsRaum und eine weiter Klasse HartesObjektBasis.

    jo, hier wirds ungewöhnlich. sind die nichtzusammenstoßbaren objekte in der überzahl? lohnt sich das sparen?

    sollen wirklich zusammenstoßbare objekte und nichtzusammenstoßbare objekte in der selben liste verwaltet werden? wie machste die kollisionchecks? gehste durch die ganze liste und checkst erstmal mit rtti, ob's ein zusammenstoßbares ist? nee, sicher nicht. vielleicht sind ja doch alle zusammenstoßbar, nur melden die faktisch nicht zusammenstoßbaren immer false beim kollisionstest. dann könnten davon die echt zuzsammenstoßbaren erben und ein paar attribute mehr haben und ehrliche antworten geben.

    Ist das gut so oder habe ich den Zweck von Mehrfachvererbung nicht verstanden?

    ja, ist gut. das einzige, was stört, ist die mehrfachvererbung. aber das wußtest du auch vorher.
    man meidet ME eigentlich aus schiss, daß wieder das alles passiert, was beim letzten mal passiert ist.

    0
  • ?

    jo, hier wirds ungewöhnlich. sind die nichtzusammenstoßbaren objekte in der überzahl? lohnt sich das sparen?

    Ich wollte den Raum eigentlich wiederverwendbar machen, also es kann sein, dass sie einmal die zusammenstoßbaren Objekte in der Überzahl, ein anderes mal kann es aber auch sein, dass es nur keine zusammenstoßbaren Objekte gibt. Also wäre es gut wenn man das ganze System abgeschaltet wäre wenn man von vorn herein weis, dass man es diesmal nicht brauchen wird.

    sollen wirklich zusammenstoßbare objekte und nichtzusammenstoßbare objekte in der selben liste verwaltet werden?

    Jein, ich hab 2 Listen in der eine sind alle Objekte, diese ist in Raum, und in der anderen alle zusammenstoßbare Objekte, diese ist in KollisionsRaum.

    Somit weis Raum und sowohl KollisionsRaum sofort auf welche Objekte es achten muss und jeder Check ob es ein zusammenstoßbares Objekte ist fällt weg.

    Gut dann werd ich mich mal versuchen und sehn ob es was wird.

    0
  • V

    mir will das nicht in den kopp hinein!
    für mich ist ein Objekt ein allgemeines Ding. Das kann an sich gar nix, außer da sein.
    und ein Körper ist ein Objekt, das Raum einnimmt.
    ein Körper HAT ein Volumen. er IST kein Volumen.
    nur Körper können kollodieren. Stecke sie ruhig in ne Körperliste.
    und die Objekte alle (auch die Körper) steck doch in ne Objektliste.

    und bis dahin lies http://www.c-plusplus.net/forum/viewtopic.php?p=532117#532117

    0
  • V

    Irgendwer schrieb:

    Einige Objekte können aber mit anderen zusammen stoßen, also muss ich auf Kollision test. Dadurch wird aber Raum und ObjektBasis ein Stück größer, also wollte ich eine weiter Klasse KollisionsRaum und eine weiter Klasse HartesObjektBasis. Objekte die zusammen stoßen können lasse ich von ObjektBasis und HartesObjektBasis erben und trage sie in Raum und KollisionsRaum ein.

    warum erbt HartesObjektBasis nicht von ObjektBasis?
    dann erben deine Objekte, die zusammenstoßen können von HartesObjektBasis und die anderen nur von ObjektBasis.

    0
  • ?

    mir will das nicht in den kopp hinein!
    für mich ist ein Objekt ein allgemeines Ding. Das kann an sich gar nix, außer da sein.
    und ein Körper ist ein Objekt, das Raum einnimmt.
    ein Körper HAT ein Volumen. er IST kein Volumen.
    nur Körper können kollodieren. Stecke sie ruhig in ne Körperliste.
    und die Objekte alle (auch die Körper) steck doch in ne Objektliste.

    und bis dahin lies http://www.c-plusplus.net/forum/viewtopic.php?p=532117#532117

    Langer rede kurzer Sinn ich soll Komposition nehmen?

    Da gibt es aber ein Problem:

    class Obj{
public:
  virtual void farbe_wechseln();
};
class Korper{};
class Obj1:public Obj{
  Korper korper;
public:
};
class Obj2:public Obj{
  Korper korper;
public:
};

    Sagen wir mal Obj1::korper stößt mit Obj2::korper zusammen und dann soll Obj1 die Farbe wechseln. Wie mach ich das nun? In meiner Körperlist weis ich ja nicht wem welchen Körper gehört also wie kann ich eine Methode von Obj1 aufrufen?

    Ich könnte eine Reference in Korper reinpacken, dies macht aber nur bedingt Sinn da dann Korper und Obj1 festverschraubt sind. Hat man einen hat man beide also sind sie untrennbar und somit sehe ich eigentlich Unterschied zu Vererbung, wenn man mal von der zusätzlichen Indirektion und möglichen Namensproblemen absieht.

    Wenn du nun sagts, dass nicht das Objekt farbig ist sondern der Korper, dann hast du dich im Kreis gedreht. Es ging ja darum die Kollision Element als optionale Erweiterung zu betrachten da diese unter Umständen sehr langsam sein können und nicht immer gebraucht werden, allerdings dann hast du nur alles von Objekt in Korper verlagert und nicht verändert.

    0
  • V

    ok, in c++ spricht sich's besser.

    class Obj{ 
public: 
}; 
class Koerper:public Object{
public: 
}; 
class Himmel:public Obj{ 
public: 
}; 
class Haus:public Koerper{ 
public: 
};

    nebst

    vector<Obj*> aleObjekte;
//und 
vector<Koerper*> alleKoerper;
    0
  • ?

    warum erbt HartesObjektBasis nicht von ObjektBasis?
    dann erben deine Objekte, die zusammenstoßen können von HartesObjektBasis und die anderen nur von ObjektBasis.

    (Als ich das letzte mal geantwortet habe hab ich den Post nicht gesehn. Wahrscheinlich zu gleichen Zeit gepostet oder so)

    Den Grund dafür hab ich eigentlich auch noch nicht gepostet (der Einfacheit zu liebe), hier hab ich nur von KollisionsRaum gesprochen allerdings gibt es da noch andere und ich will das ganz offen halten um, wenn ich noch welche brauche hinzufügen, zu können. Wenn nun KollisionsRaum von Raum erbt kann ich da nicht noch eine andere Klasse reinbringen ohne KollisionsRaum oder Raum zu verändern. Ausser wenn ich so was mache:

    class Raum{}
template<class Parent>
class RaumA:public Parent{};
template<class Parent>
class RaumB:public Parent{};
template<class Parent>
class RaumC:public Parent{};
//...
RaumC<RaumA<Raum> >raum;

    Find ich aber ehrlich gesagt unübersichtlicher als die Mehrfachvererbung.

    class Obj{ 
public: 
}; 
class Koerper:public Object{
public: 
}; 
class Himmel:public Obj{ 
public: 
}; 
class Haus:public Koerper{ 
public: 
};

    Ich nehm Mal an, dass du mit Object und Obj das gleiche meinst. Ich will das nicht weil ich nicht nur Koerper habe es gibt auch noch andere solcher Klassen. So wie du verschlägst hatte ich es eine Zeit lang und das ist zwar ein gutes Design aber Objekt/Raumerweiterung gegenüber sehr feindlich da man dann jeweils eine Verion für Koerper und für Obj machen muss, will man dann noch so ne Erweiterung ist man bei 4 neuen Klassen. Desweiteren wenn einer eine Erweiterung schreibt und der andere auch sie aber von der gleichen Klasse ausgehen dann kann man immer nur eine benutzen.

    Ich hab jetzt mit der Mehrfachvererbung angefangen, schein zu funktionieren.

    0
Anmelden zum Antworten