Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

[Erledigt] Observer Pattern: rein virtuellen Methoden?

Werbeanzeige

Das Gurke

Community-Fossil

  • »Das Gurke« ist der Autor dieses Themas

Beiträge: 1 996

Wohnort: Pinneberg

Beruf: Schüler

  • Private Nachricht senden

1

09.08.2008, 11:22

[Erledigt] Observer Pattern: rein virtuellen Methoden?

Ich bin gerade dabei eine Art "allgemeine" Client Library für mein Projekt zu entwerfen, welche mir beim schreiben möglicherweise mehrerer Clients grundlegende Aufgaben abnehmen soll. Dabei wollte ich auf das Observer Pattern setzen.

Nun bietet das Visual Studio für C++ leider keine praktische "abstrakte Member implementieren" Funktion. Je "größer" die möglichen Listening Interfaces also werden, desto mehr wird das *wirklich* nervig alle Methoden immer wieder aufs neue zu implementieren. Zumal man nicht immer alles brauchen wird und man dann mit verdammt vielen "leeren" Methodenrümpfen umherläuft.

Ich hatte daher daran gedacht, die Listener Interfaces nicht komplett abstrakt zu machen, sondern einige "Callbacks" mit einem Methodenrumpf auszustatten. Das ganze ähnelt dann etwas mehr den "Adapter" Klassen aus Java. Also zum Beispiel so:

C-/C++-Quelltext

 
1
2
3
4
5
6

class ConnectionListener
    {
    public:
        virtual void connectionLost() = 0;
        virtual void connectionMade() {}
    };


1) Schlägt das irgendwie auf die Performance? Ich vermute zwar nicht, weils so oder so virtual ist, aber ich würd meinen Arsch nicht drauf verwetten.
2) Ist das überhaupt eine gute Idee bzw. bau ich damit was extrem unnormales?
http://trash.gurxite.de/userbarmarcusbloggt.png
http://img.flowergame.net/flower/77.pnghttp://img.flowergame.net/flower/221.pnghttp://img.flowergame.net/flower/223.png

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

2

09.08.2008, 16:50

Da du die Methoden ja nicht dauernd aufrufst, würde ich mir um das Problem Leistung weniger Sorgen machen :) . Und prinzipiell spricht ja nichts gegen diesen Weg. Allerdings würde mich interessieren, warum du gerne mehrere Beobachter registieren möchtest bei einer Clientinstanz, oder bin ich gerade auf dem falschen Dampfer?
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

Das Gurke

Community-Fossil

  • »Das Gurke« ist der Autor dieses Themas

Beiträge: 1 996

Wohnort: Pinneberg

Beruf: Schüler

  • Private Nachricht senden

3

09.08.2008, 16:57

Naja, ich geh da lieber nach dem Motto "sicher ist sicher" vor. Bei OIS hat es mich zum Beispiel relativ stark gestört, dass ich nur einen Listener anmelden konnte. Da hab ich das dann selber implementiert. Und vielleicht möchte ja jemand ein Listener als Teil einer Fensterklasse und einen Listener als Teil der Spiellogik implementieren. Ich hab mir da jetzt nicht riesig Gedanken drum gemacht ^^

Primär geht es ja darum die Entwicklung von Clients zu vereinfachen, indem die ganzen "Lowlevel" Sachen in der Client Library versteckt werden. Im Optimalfall muss der Client nur auf Events reagieren und sich kein Stück um den Netzwerkunterbau kümmern.

Edit: Aber nachdem sich auch im IRC niemand so richtig gegen diesen Vorschlag ausgesprochen hat, mach ich das erstmal so.
http://trash.gurxite.de/userbarmarcusbloggt.png
http://img.flowergame.net/flower/77.pnghttp://img.flowergame.net/flower/221.pnghttp://img.flowergame.net/flower/223.png

Werbeanzeige