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!
Werbeanzeige
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »dot« (04.09.2012, 14:25)
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?
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?
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »stef« (04.09.2012, 14:44)
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
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...
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?
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...
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
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.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.
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.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...
Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »BlueCobold« (04.09.2012, 15:12)
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...
Werbeanzeige