RAII
-
314159265358979 schrieb:
seldon schrieb:
Etwa, wenn ich eine Datumsklasse schreibe und der umgebende Code versucht, den 53. Juni zusammenzustellen.
Ist hierfür ein assert() nicht besser geeignet?
Meiner Meinung nach sollten Exceptions nur dort verwendet werden, wo die Zuständigkeit des Programmierers endet. Zum Beispiel bei IO.Äh...assert ist eigentlich als Debugging-Tool gedacht. Es ist die Aussage "hier muss dies oder das der Fall sein, sonst ist irgendwo ein Programmierfehler gemacht worden". Üblicherweise wird das aus Releaseversionen ja auch einfach rauskompiliert.
Jedenfalls ist der Gedanke genau falsch herum - einfach abzustürzen ist in Ordnung, wenn dir Hardware abraucht oder sonstige Dinge passieren, für die du nun wirklich überhaupt nicht planen kannst, aber kein Benutzer dankt es dir, wenn dein Programm abstürzt, bloß weil er sich in einem Eingabefeld vertippt. Und die Prüfung, ob es sich um ein gültiges Datum handelt, aus der Datumsklasse herauszunehmen, wäre für mein Verständnis ziemlich geisteskrankes Design.
Was die "Zwei-Phasen-Initialisierung" angeht: Diese Problematik ist von RAII völlig abgekoppelt. Ob ein Objekt initialisiert ist, ist eher eine programmlogische Frage - ein std::vector ist initialisiert und einsatzbereit, bevor er das erste mal Speicher anfordert, und den Speicher, den er anfordert, kann er auch während seiner Lebensdauer wieder freigeben (wenn er beispielsweise vergrößert wird).
Worum es bei RAII geht, ist, dass Ressourcen, sobald sie angefordert wurden, sofort einem Eigentümer unterstellt werden, der sich um ihre spätere Freigabe kümmert. Wie und wann der das macht, ist eine andere Frage; wichtig ist allein, dass nichts verloren geht (Destruktoren spielen hier natürlich eine große Rolle, aber nicht alle Ressourcen werden erst im Destruktor freigegeben, und nicht alle Destruktoren geben verwaltete Ressourcen wieder frei - shared_ptr lässt grüßen). Ob die Eigentümerschaft über Ressourcen bereits im Konstruktor oder später übernommen wurde, ist dafür gleichgültig.
-
SeppJ schrieb:
Wie kommst du den da drauf? Es soll durchaus möglich sein, den Objektzustand später noch zu verändern.
Wobei durchaus die Meinung existiert zumindest Value Objects, also Objekte deren Identität durch ihren Zustand bestimmt ist immutable zu machen, also keine Setter anzubieten und stattdessen immer neue Objekte zu verwenden.
Wobei das denke ich in C++ weniger bedeutsam ist als in C# oder Java. Ich habe die Bedeutung zumindest aus C++ Sicht nie wirklich verstanden, wenn ich davon las.
-
brotbernd schrieb:
Wobei durchaus die Meinung existiert zumindest Value Objects, also Objekte deren Identität durch ihren Zustand bestimmt ist immutable zu machen, also keine Setter anzubieten und stattdessen immer neue Objekte zu verwenden.
Wobei das denke ich in C++ weniger bedeutsam ist als in C# oder Java. Ich habe die Bedeutung zumindest aus C++ Sicht nie wirklich verstanden, wenn ich davon las.Das klingt in C++ nach einem Fall für const. Wobei ich kein großer Fan von temporären const-Objekten bin, sofern das nicht der Compilezeitoptimierung dient. Ich sollte als Programmierer selber wissen, ob ich meine Objekte verändern will oder nicht. Wenn ich den Begriff Value Object richtig verstehe, macht das dort aber durchaus Sinn - das ist dann wohl auch wieder so etwas wie eine Compilezeitkonstante.
-
Hm ich weiß nicht.. Ich hab neulich Evans 'Domain Driven Design' gelesen, da hat er sich darüber ausgelassen. Ich habs nicht wirklich verstanden. Bei Fowler hab ich sowas auch mal gelesen. Die Sachen sind aber oft ziemlich von Java geprägt, darum hab ich vermutet dass das irgendwie in der Ecke seinen Ursprung hat.
-
Ich kenne mich mit fortschrittlichem Java-Design nicht so aus, aber ist nicht so etwas gemeint?
int zehn = 10; date erster_januar = Date(1,1); string hello_world = "Hello World!";Das sind so typische Fälle (hier ein bisschen an den Haaren herbeigezogen, weil ich gerade faul bin), wo die Identität eines Objekts gleichbedeutend mit seinem Wert ist und wo es durchaus Sinn macht, diese deshalb vor Veränderung zu schützen. Was immer das jeweilige Mittel der Sprache zu diesem Zweck ist.
Aber wir entgleisen gerade den Thread...
-
dot schrieb:
krümelkacker schrieb:
[...]
Ob nun "Zwei-Phasen-Initialisierung" oder nicht, ist eine andere Geschichte. Ich würde hier immer noch von RAII sprechen. Ob eine Klasse noch einen "Nullzustand" bekommen soll oder nicht, muss man für sich im konkreten Fall entscheiden.
"Zwei-Phasen-Initialisierung" ist eigentlich schon ein Widerspruch in sich.
Wie gesagt, das versteht wohl jeder etwas anders. Initialisierung gibt es in zweierlei Hinsicht: (1) Die Sprache C++ selbst verwendet das Wort "Initialisierung" in Kombination mit "direct initialization", "copy initialization" oder "list initialization", jeweils verschiedene Syntaxen für die Initialisierung. (2) "Logische" Initialisierung = Initialisierung im Sinne von Punkt 1 oder Veränderung eines existierenden Objekts in einen Zustand, den man bei der anwendungsspezifischen Modellierung als "initialisiert" betrachtet (was auch immer das sein wird). Wenn man bei RAII an den zweiten Punkt denkt, passt auch "two-phase-initialization" in das Konzept rein.
Ich ziehe es vor, die Dinge unabhängig voneinander zu betrachten. Bei der einen Sache geht es darum, Resourcen irgendwelchen Besitzer-Objekten zuzuordnen und damit Verwaltungsaufwand zu deligieren und für Ausnahmesicherheit zu sorgen. Bei der anderen Sache geht es darum, ob für die entsprechende Klasse ein "Nullzustand" eher nützt oder schadet. Bei Klassen wie std::string, std::vector und std::unique_ptr<> macht so ein Zustand, in dem keine zusätzlichen Resourcen benötigt werden, durchaus Sinn. Bei den stream-Klassen ist das eher eine Grauzone, würde ich sagen. Wenn diese Stream-Klassen einen solchen Zustand nicht anböten, man ihn aber für eine bestimmte Anwendung gut gebrauchen könnte, müsste man sich so etwas mit boost::optional oder std::unique_ptr nachbauen. Ob so ein Nullzustand für eine Klasse sinvoll ist, kann ich pauschal nicht beantworten. Das kommt auch darauf an, wieviel Aufwand es ist, so einen Nullzustand in die Invariante aufzunehmen und wie nervig es im Benutzercode sein wird, auf diesen Zustand prüfen zu müssen.
dot schrieb:
Mit einer Init Methode ist die Verwaltung der Ressource von der Lebensdauer des Objektes zumindest halb entkoppelt. Im Falle von fstream ist durch open() und close() praktisch alles von der Lebensdauer entkoppelt, das Objekt stellt nur noch die Freigabe der Ressource in jedem Fall sicher.
Ein Objekt, kann die Verwaltung einer Resource nur übernehmen, sofern es existiert -- nicht vorher und nicht nachher. Was während der Existenz des Objekts passiert (swap, move semantics, open/close etc), ist mir egal. Hautsache Resourcen werden schnellstmöglich einem Besitzer-Objekt zugeordnet. Das und nur das verstehe ich unter RAII, wie schon erwähnt. Wenn Du einen anderen Begriff dafür hast, sag ihn mir. Klassen mit hohem Aufwand auf beiden Seiten der Schnittstelle einen künstlichen "Nullzustand" aufzuzwängen, halte ich aber auch für eine blöde Idee. Die Stream-Klassen fühlen sich IMHO wie unique_ptr für spezielle Stream-Buffer an. Da kann ich auch einen Nullzustand tolerieren.
dot schrieb:
Streng genommen entspricht das also nichtmehr der Bezeichnung RAII.
Mit der Bezeichnung ist sowieso keiner glücklich.
Gruß,
kk
-
seldon schrieb:
...
Ah, Deinen Beitrag hatte ich übersehen. Da hätte ich mir die lange Antwort sparen können.
-
SeppJ schrieb:
Ich kenne mich mit fortschrittlichem Java-Design nicht so aus, aber ist nicht so etwas gemeint?
int zehn = 10; date erster_januar = Date(1,1); string hello_world = "Hello World!";Das sind so typische Fälle (hier ein bisschen an den Haaren herbeigezogen, weil ich gerade faul bin), wo die Identität eines Objekts gleichbedeutend mit seinem Wert ist und wo es durchaus Sinn macht, diese deshalb vor Veränderung zu schützen. Was immer das jeweilige Mittel der Sprache zu diesem Zweck ist.
Aber wir entgleisen gerade den Thread...
Ja, das geht schon in die Richtung (hab grad nochmal bischen gelesen). Es hat eigentlich nicht mit sprachspezifischen Techniken zu tun, sondern ist rein konteptionell. Value objects sollen nicht verändert werden, weil man dadurch deren Identität ändern, die ja durch den Zustand des Objekts bestimmt ist.
D.h.erster_januar = Date(1,1);wird immer der erste_januar sein. Will ich ein anderes Datum schmeiß ich den ersten_januar weg und hol mir einen neuenzweiten_februar = Date(2,2);
Das hat jetzt zwar was mit Initialisierung zu tun, aber tatsähclich nicht mehr viel mit RAII... als schlusss
-
brotbernd schrieb:
[...] Value objects sollen nicht verändert werden, weil man dadurch deren Identität ändern, die ja durch den Zustand des Objekts bestimmt ist.
wtf?!
Wenn ich Dir einen neuen Haarschnitt verpasse, bekommst Du ja nicht automatisch einen neuen Namen oder bekommst plötzlich eine neue Anschrift, oder? Deine Identität ist noch dieselbe -- auch nach der "Mutation".
Oder: Was ist Deine Definition von "Value Objects"? Denkst Du wirklich gerade in C++ oder vielleicht doch in einer anderen Sprache, wo man für "Wertsemantik" gerne mal Referenzen + konstante Objekte + Garbage-Collector nutzt?
-
Es geht nicht um ein bestimmtes Sprachfeature, sondern um Objekte, deren Identität durch ihren Zustand bestimmt sind. Eine Zahl ist ein Value Object. Die 42 ist immer 42. Würde ich den Zustand von 42 ändert, z.B. einfach eins drauszählen, dann hätte ich ein ganz anderes Objekt.
Ich bin dagegen kein Value Object sondern ein Entity, da ich eine Identität habe. Änderst du meinen Haarschnitt, bin ich immer noch ich.
Das gehört aber eigentlich nicht hierhin. Ich wollte nur erwähnen, dass es abseits vom RAII Thema für bestimmte Klassen doch Philosophien gibt, Objekte nur über den Konstruktor zu initialisieren.
-
seldon schrieb:
Äh...assert ist eigentlich als Debugging-Tool gedacht. Es ist die Aussage "hier muss dies oder das der Fall sein, sonst ist irgendwo ein Programmierfehler gemacht worden". Üblicherweise wird das aus Releaseversionen ja auch einfach rauskompiliert.
Und genau das möchte ich erreichen. Im Debug möchte ich den User auf einen Fehler hinweisen, im Release möchte ich ihn nicht mit zusätzlichen, unnötigen Überprüfungen belasten.
seldon schrieb:
Und die Prüfung, ob es sich um ein gültiges Datum handelt, aus der Datumsklasse herauszunehmen, wäre für mein Verständnis ziemlich geisteskrankes Design.
Selbstverständlich sollte sowas überprüft werden. Aber im Idealfall nur im Debug, und genau das tut assert.
-
brotbernd schrieb:
Es geht nicht um ein bestimmtes Sprachfeature, sondern um Objekte, deren Identität durch ihren Zustand bestimmt sind.
Das ergibt für mich immer noch keinen Sinn. Zustand und Objekt-Identität sind unabhängig (in C++).
brotbernd schrieb:
Eine Zahl ist ein Value Object.
In welchem Gedankenrahmen? Sind wir jetzt bei abstrakter Mathematik angekommen?
brotbernd schrieb:
Die 42 ist immer 42. Würde ich den Zustand von 42 ändert, z.B. einfach eins drauszählen, dann hätte ich ein ganz anderes Objekt.
Was mathematische Objekte genau sind, darüber sind sich die Philosophen nicht ganz einig. Ich würde aber behaupten, dass sie keine "Zustände" haben.
Und in C++ ist 42 ein Ganzzahlliteral. Als solches bezieht es sich nicht auf ein Objekt (siehe C++ ISO Standard).
-
Was hat der user mit der debug-Version zu tun? Damit kommt er doch garnicht in Kontakt.
Und selbstverständlich sollte das release bei einer Datumseingabe auch eine Gültigkeitsprüfung vornehmen.
-
Natürlich kommt der User mit der Debug-Version in Berührung, nämlich wenn er bei sich den Debug-Schalter betätigt.
Und ja, die Eingabe sollte geprüft werden, aber nicht von der Klasse sondern vom Benutzer der Klasse!
-
314159265358979 schrieb:
Natürlich kommt der User mit der Debug-Version in Berührung, nämlich wenn er bei sich den Debug-Schalter betätigt.
Manchmal ist es besser, wenn man einsieht, dass man Unrecht hatte, anstatt sich noch tiefer ins Schlamassel zu reiten.
-
Nochmal:
User sagt: "Ey Compiler, mach mal Debug!"
Klasse sagt: "Hey, hier ist ein assert, check das mal!"User sagt: "So Compiler, alles getestet, Release bitte!"
Klasse sagt: "Hey User, wenn du was falsche übergibts, bist du selbst schuld!"Jetzt klarer was ich meine? Der User soll dabei IMMER selbst überprüfen, im Debug soll die Klasse zusätzlich checken, im Release hat der User pech gehabt.
-
314159265358979 schrieb:
seldon schrieb:
Und die Prüfung, ob es sich um ein gültiges Datum handelt, aus der Datumsklasse herauszunehmen, wäre für mein Verständnis ziemlich geisteskrankes Design.
Selbstverständlich sollte sowas überprüft werden. Aber im Idealfall nur im Debug, und genau das tut assert.
Es ist gemeint, dass der Nutzer (nicht der Programmierer) in einer Eingabemaske ein Datum eingibt und daraus dann im Programm ein Datumsobjekt erzeugt wird. Natürlich passiert das auch in der Releaseversion. Und wenn der Nutzer meint, den 53. Juli eingeben zu müssen, muss das das Programm abfangen. Wer aber soll wissen, was ein gültiges Datum ist, wenn nicht die Datumsklasse selbst?
-
krümelkacker schrieb:
..
Wie gesagt, geht es weder um C++, Java oder Mathematik. Die Zahl 42 war nur ein sehr einfaches Beispiel. Von mir aus nimm ein Datum oder ein Namen.
Das sind halt Begriffe aus dem Domain Driven Design. Ich muss allerdings sagen, dass ich das auch noch nie so streng befolgt habe. Ich unterscheide gedanklich zwar schon Entities und Value Objects lasse aber meist auch Modifikationen an Value Objects zu, da es mir einfach zu blöd ist alles neu zu initialisieren (oder vor allem in vielen Fällen auch einfach zu ineffizient).
