spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ok, das war nicht gut ausgedrückt was ich eigentlich damit sagen wollte. Machen wir's anders: Woher weißt du, wie die Objekte zu löschen sind? Und wie stellst du sicher, dass die Objekte nur auf die richtige Art und Weise gelöscht werden können? Kann es sein, dass Objekte mit dem gleichen Interface auf verschiedene Art zu löschen sind? Wenn nein, dürfen sie auch nur auf die gleiche Art erzeugt werden. Wenn ja, sollte man drüber nachdenken, ob das Interface nicht fehl am Platz ist, da die Objekte hinter dem Interface nun abhängig von ihrem dynamischen Typ unterschiedlich behandelt werden müssen, das Liskovsche Substitutionsprinzip ist verletzt...

Zitat von »dot«

Ok, das war nicht gut ausgedrückt was ich eigentlich damit sagen wollte. Machen wir's anders: Woher weißt du, wie die Objekte zu löschen sind? Und wie stellst du sicher, dass die Objekte nur auf die richtige Art und Weise gelöscht werden können?

Bin mir immer noch nicht sicher ob ich weis worauf du hinaus willst.
Welche Methoden zum löschen eines Objektes gibt es denn ?
Wenn es auf dem Stack liegt wird es automatisch abgebaut wenn das Programm
den Scope verlässt in dem das Objekt angelegt worden ist.
Wenn du das Objekt mit new erzeugts sollte irgendwo ein delete erfolgen.
Temoräre Objekte werden auch automatisch vom Kompiler abgebaut.
In allen Fällen wird der Destruktor der Klasse aufgerufen.
Arbeitet man nicht polymorph werden automatisch alle Destruktoren der Basisklassen aufgerufen.
Arbeitet man polymorph erreicht man das selbe durch virtuelle Destruktoren.
Wenn jetzt jeder Destruktor hinter seiner eigenen Klasse aufräumt hat man keine Sorgen.

Hab vorhin noch was editiert, vielleicht wird's damit etwas klarer?

Abgesehen davon:

Zitat von »stef«

Ich verstehe kein Wort !
Kannst du das auch in verständlichem Deutsch beschreiben.

Nehmen wir ein Beispiel aus der echten Welt. Dazu erstmal eine Frage an dich: Was verstehst du rein konzeptuell unter einer Lichtquelle?

Zitat von »dot«

Nehmen wir ein Beispiel aus der echten Welt. Dazu erstmal eine Frage an dich: Was verstehst du rein konzeptuell unter einer Lichtquelle?

Ein bestimmter Punkt im Raum der Licht emittiert.



Huch, wo bin Ich ????

Zitat von »dot«

Ok, das war nicht gut ausgedrückt was ich eigentlich damit sagen wollte. Machen wir's anders: Woher weißt du, wie die Objekte zu löschen sind? Und wie stellst du sicher, dass die Objekte nur auf die richtige Art und Weise gelöscht werden können? Kann es sein, dass Objekte mit dem gleichen Interface auf verschiedene Art zu löschen sind? Wenn nein, dürfen sie auch nur auf die gleiche Art erzeugt werden. Wenn ja, sollte man drüber nachdenken, ob das Interface nicht fehl am Platz ist, da die Objekte hinter dem Interface nun abhängig von ihrem dynamischen Typ unterschiedlich behandelt werden müssen, das Liskovsche Substitutionsprinzip ist verletzt...

Sorry, ich sehe den roten Faden noch immer nicht. Wenn das Interface einen public virtual Destruktor vorschreibt, dann kann ich sie doch löschen, wie ich lustig bin. Entweder über einen Basis-Klassen-Zeiger oder über eine direkte Klassen-Typ-Verwendung, als per new erzeugte Heap-Instanz, sowie auch als Stack-Instanz.
Somit ist weder das Interface fehl am Platz, noch verletze ich das L-S-Prinzip. Es gibt keine "richtige" Art sie zu löschen in diesem Fall.
Kannst Du es nochmal anders formulieren, dass ich den Punkt sehe, den ein solches Interface gefährdet?
Oder übersehe ich irgendwas?

Zitat von »BlueCobold«

Zitat von »dot«

Ok, das war nicht gut ausgedrückt was ich eigentlich damit sagen wollte. Machen wir's anders: Woher weißt du, wie die Objekte zu löschen sind? Und wie stellst du sicher, dass die Objekte nur auf die richtige Art und Weise gelöscht werden können? Kann es sein, dass Objekte mit dem gleichen Interface auf verschiedene Art zu löschen sind? Wenn nein, dürfen sie auch nur auf die gleiche Art erzeugt werden. Wenn ja, sollte man drüber nachdenken, ob das Interface nicht fehl am Platz ist, da die Objekte hinter dem Interface nun abhängig von ihrem dynamischen Typ unterschiedlich behandelt werden müssen, das Liskovsche Substitutionsprinzip ist verletzt...

Sorry, ich sehe den roten Faden noch immer nicht. Wenn das Interface einen public virtual Destruktor vorschreibt, dann kann ich sie doch löschen, wie ich lustig bin. Entweder über einen Basis-Klassen-Zeiger oder über eine direkte Klassen-Typ-Verwendung, als per new erzeugte Heap-Instanz, sowie auch als Stack-Instanz.
Somit ist weder das Interface fehl am Platz, noch verletze ich das L-S-Prinzip. Es gibt keine "richtige" Art sie zu löschen in diesem Fall.
Kannst Du es nochmal anders formulieren, dass ich den Punkt sehe, den ein solches Interface gefährdet?
Oder übersehe ich irgendwas?

Es geht nicht darum, dass du das Objekt über den Basisklassenzeiger löschen kannst. Natürlich geht das. Der Punkt ist: Woher weiß der Verwender deines Interface, wie genau das Objekt über den Basisklassenzeiger zu löschen ist, wenn er das Objekt nicht selbst erzeugt hat. Wer das Objekt selber erzeugt, braucht keinen Basisklassenzeiger...

Zitat von »stef«

Ein bestimmter Punkt im Raum der Licht emittiert.

Richtig. Wie du siehst, haben die Herstellungsprozesse von LEDs gleich wie die sachgerechte Entsorgung defekter Energiesparlampen nichts mit dem rein abstrakten Konzept einer Lichtquelle zu tun...

Zitat von »dot«

Richtig. Wie du siehst, haben die Herstellungsprozesse von LEDs gleich wie die sachgerechte Entsorgung defekter Energiesparlampen nichts mit dem rein abstrakten Konzept einer Lichtquelle zu tun...

und ... ???

Mir fehlt hier der praktische Bezug auf OOP.

Durch Polymorphie drückst du abstrakte Konzepte aus. Ein Interface Lichtquelle drückt das Konzept einer Lichtquelle aus. Wieso sollte dieses Interface einen virtuellen Destruktor vorgeben, wenn die Erzeugung und Zerstörung von konkreten Objekten, die Lichtquellen sind, nicht Teil des Konzeptes einer Lichtquelle ist? Sinn des Interface ist, dass du generischen Code schreiben kannst, der mit "Punkten im Raum, die Licht emittieren" arbeitet. Woher die konkreten Lichtquellen kommen und wohin sie gehen ist dafür völlig irrelevant...

Zitat von »dot«

Es geht nicht darum, dass du das Objekt über den Basisklassenzeiger löschen kannst. Natürlich geht das. Der Punkt ist: Woher weiß der Verwender deines Interface, wie genau das Objekt über den Basisklassenzeiger zu löschen ist, wenn er das Objekt nicht selbst erzeugt hat.

Das sollte ihm entweder egal sein dürfen oder er sollte nicht in der Lage sein das Objekt zu zerstören - logisch, denn wenn ich nicht weiß wie, dann sollte ich es nicht dürfen, da ich es sonst eben falsch mache. Sagt mir leider noch immer nicht, wieso ein Interface keinen public virtual Destruktor vorgeben sollte.

Zitat von »dot«

Wie du siehst, haben die Herstellungsprozesse von LEDs gleich wie die sachgerechte Entsorgung defekter Energiesparlampen nichts mit dem rein abstrakten Konzept einer Lichtquelle zu tun...

Dieses Argument empfinde ich als Grund für das Nichtvorhandensein eines virtuellen Destruktors in einem Interface als gültig und durchaus sinnvoll. Dennoch ist in OOP nunmal generell ein Konstruktor und Destruktor (explizit oder implizit) erforderlich, da ein Objekt erzeugt und vernichtet werden *muss*. Eine LED wird eigentlich nicht durch eine LED erzeugt und sie weiß nicht, wie sie erzeugt oder entsorgt wird. In OOP lässt sich dies aber nicht korrekt darstellen, nur über Konstruktor und Destruktor. Für die Lichtquelle macht ein Destruktor an dieser Stelle logisch keinen Sinn. Wenn mir eine Fabrik aber viele verschiedene Arten Lichter liefert, dann bleiben mir zwei Wege: Entweder die Fabrik muss sie auch entsorgen können (was nicht Sinn einer Fabrik ist) oder ich muss es selbst können. Letzteres führt wieder zu einem semantischen Problem, da das Licht dann etwas können müsste, was es nicht können sollte.
Ach, ich mag Sprachen mit Garbage Collection

Zitat von »BlueCobold«

Zitat von »stef«

Wie du siehst, haben die Herstellungsprozesse von LEDs gleich wie die sachgerechte Entsorgung defekter Energiesparlampen nichts mit dem rein abstrakten Konzept einer Lichtquelle zu tun...

Das ist ein Zitat von DOT ...