RAII

brotbernd

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 neuen zweiten_februar = Date(2,2);
Das hat jetzt zwar was mit Initialisierung zu tun, aber tatsähclich nicht mehr viel mit RAII... als schlusss

krümelkacker

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?

brotbernd

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.

314159265358979

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.

krümelkacker

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).

inter2k3

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.

314159265358979

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!

SeppJ

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.

314159265358979

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.

ipsec

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?

brotbernd

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).