Name für disposeähnliches Interface

Dravere

Q schrieb:

Bisher habe ich einfach IDisposable implementiert. Mir ist jetzt aber aufgefallen, dass das ja eigentlich nur für unmanaged ressourcen ist.

Wieso? Ich finde das eine völlig unnötige Einschränkung.

Die Frage ist allerdings, wieso musst du überhaupt die Objekte freigeben? Was macht deine Freigabemethode? Vorher lässt sich nur schwer sagen, wie du die Methode am besten nennst.

Grüssli

inflames2k

Ich nutze auch für Objekte, die zur Laufzeit freigegeben werden müssen unabhängig davon, ob sie auf Unmanaged Ressourcen zurück greifen IDisposable. Die Einschränkung, das dieses nur für den einen Fall zu verwenden ist gibt es nicht. Insofern bietet IDisposable eine einheitliche Schnittstelle zur Freigabe von Objekten, unabhängig davon was in diesen Intern passiert.

Mechanics

inflames2k schrieb:

Ich nutze auch für Objekte, die zur Laufzeit freigegeben werden müssen unabhängig davon, ob sie auf Unmanaged Ressourcen zurück greifen IDisposable.

Es ist keine Einschränkung, aber ich finde der Name passt einfach nicht. Die Schnittstelle zu implementieren bringt dir ja noch nichts. Da kann man genauso gut eine eigene Schnittstelle definieren, die besser passt.

Dravere

Mechanics schrieb:

Es ist keine Einschränkung, aber ich finde der Name passt einfach nicht. Die Schnittstelle zu implementieren bringt dir ja noch nichts. Da kann man genauso gut eine eigene Schnittstelle definieren, die besser passt.

Es gibt etwas, was man nicht vergessen sollte. IDisposable ist etwas mehr als nur ein Interface. Es ermöglicht die Verwendung des using Statement. Das ist meiner Meinung nach auch der klare Vorteil von IDisposable gegenüber anderen Lösungen.

Grüssli

Mechanics

Ja, das using ist durchaus eine Überlegung wert, aber ich denke an der Stelle ist es auch kein Grund. Wenn das vom Sinn her nicht so ganz passt, würde ich das auch nicht verwenden, weil es dann verwirrt. Ist das entfernen von Gegnern von einem Spielfeld ein Fall für try ... finally ... dispose? Finde ich nicht. Außerdem werden die Objekte wahrscheinlich nicht innerhalb ein und derselben Funktion angelegt und entfernt werden.

Dravere

Mechanics schrieb:

Ja, das using ist durchaus eine Überlegung wert, aber ich denke an der Stelle ist es auch kein Grund. Wenn das vom Sinn her nicht so ganz passt, würde ich das auch nicht verwenden, weil es dann verwirrt. Ist das entfernen von Gegnern von einem Spielfeld ein Fall für try ... finally ... dispose? Finde ich nicht. Außerdem werden die Objekte wahrscheinlich nicht innerhalb ein und derselben Funktion angelegt und entfernt werden.

Daher habe ich meine Frage weiter oben in den Raum geworfen:

Dravere schrieb:

Die Frage ist allerdings, wieso musst du überhaupt die Objekte freigeben?

Nur wenn man die Hintergründe genauer kennt, kann man hier weiteres dazu sagen. Vielleicht würde sogar wirklich sowas wie WeakReference schon reichen, wie dies der Feuerteufel bereits erwähnt hat

Grüssli

*Q* 1

Um für etwas Klarheit zu sorgen:

Es geht vor allem dadrum, dass z.B. Gegner aus dem Spiel entfernt werden können. Ein using macht da wenig sinn, WeakReference auch nicht.
Ich hatte vor, evtl. auch noch ein paar andere Klassen das interface (um das es hier geht) implementieren zu lassen, z.B. könnte ein level-objekt dabei alle objekte die es besitzt freigeben, um z.B. danach neu erstellt zu werden oder einen spielstand zu laden.

inflames2k

Mechanics schrieb:

inflames2k schrieb:

Ich nutze auch für Objekte, die zur Laufzeit freigegeben werden müssen unabhängig davon, ob sie auf Unmanaged Ressourcen zurück greifen IDisposable.

Es ist keine Einschränkung, aber ich finde der Name passt einfach nicht.

In wie fern passt denn der Name nicht? Dispose heißt zu deutsch so viel wie: beseitigen, entsorgen, und viele weitere Dinge. Ich wüsst jetzt nicht, wo "beseitigen" nicht passt.

Hallo Q,

nachdem ich deinen Eingangspost noch einmal gelesen habe, frage ich mich nicht, ob das reine auf Null setzen dein Problem nicht schon löst. Da du wie du schreibst nur vor hast, das Objekt logisch aus dem Spiel zu entfernen. - Durch das Null setzen verschwindet zugleich ja auch die Referenz (sofern nur eine existiert).

Dravere

Q schrieb:

Um für etwas Klarheit zu sorgen: ...

Das hat bei mir nicht für Klarheit gesorgt. Du hast dich grundsätzlich einfach wiederholt. Was heisst denn in deinem Design einen Gegner aus dem Spiel nehmen? Was passiert dabei? Was löst das bisheriges Dispose denn aus? Kannst du dies nicht etwas genauer beschreiben?

Grüssli

Mechanics

[quote="inflames2k"]

Mechanics schrieb:

In wie fern passt denn der Name nicht? Dispose heißt zu deutsch so viel wie: beseitigen, entsorgen, und viele weitere Dinge. Ich wüsst jetzt nicht, wo "beseitigen" nicht passt.

Es kann ja durchaus passen. Aber so wie ich seine Aufgabenstellung verstanden habe, würde ich den Namen suboptimal finden. Wenn ich eine Figur vom Spiel nehme, "entsorge" ich sie nicht. Wenn ich das "entsorgen" nenne und auch noch IDisposable implementiere, wird jeder erfahrene .NET Entwickler als erstes an Ressourcenfreigabe denken und sich das ganze vielleicht nicht näher anschauen oder sich dann denken, hä, wieso macht er das jetzt über IDisposable... Ist vielleicht Haarspalterei, ich will im Endeffekt nur darauf hinweisen, dass wenn es einen besser passenden Namen gibt, man den auch verwenden sollte, auch gerade um Missverständnissen vorzubeugen.

*Q* 1

Ok, nochmal anders ausgedrückt:

Eigentlich geht es inzwischen nur noch dadrum, dass das spielobjekt dann aus einer datenstruktur des übergeordneten level-objekts entfernt wird.

Evtl. ist es sinnvoller, das jetzt einfach durch eine methode vonm levelobjekt zu lösen wie z.B. RemoveActor, dann brauchen die spielobjekte selbst das gar nicht im interface haben.

Früher war es nur so, dass Spielobjekte auch Grafikobjekte verwaltet hatten, die wiederum disposed werden mussten, weil diese teil eines bindings zu einer C++ bibliothek (SFML) sind und die C++ Destruktoren aufgerufen werden sollen.
Viele andere Klassen wie z.B. Level haben dann auch von IDisposable geerbt, weil oft Grafikobjekte mit drin hingen.

Inzwischen ist die gesamte Grafik aus der Spiellogik ausgelagert und die Spiellogik selbst braucht eigentlich kein Dispose mehr, nur noch soetwas wie aus datenstrukturen entfernen o.ä.

Von vorher erbt das interface IActor aber noch von IDisposable. Ich werd das dann jetzt rausnehmen.

Was hattest du Anfangs vor? Wolltest du das Spielobjekt sich selbst aus dem Spiel entfernen lassen?

Dravere

Q schrieb:

Evtl. ist es sinnvoller, das jetzt einfach durch eine methode vonm levelobjekt zu lösen wie z.B. RemoveActor, dann brauchen die spielobjekte selbst das gar nicht im interface haben.

Ja. Definitiv. Zumindest so wie du es hier beschreibst.

Grüssli