S
newkid schrieb:
die dann die daten nach plausibilität, und nach kennungen ( raucher, weiblich, unter 25 ect, bush wähler usw. ) durchführen muss.
Das kommt halt darauf an. Warum willst du die Daten auf plausibilitaet testen, wenn du sie gerade der datenbank entnommen hast.
uU ist soetwas ja recht aufwendig.
Deshalb waere es uU besser einfach nur ein verifyData() zu haben, dass die struct testen.
Das kann man dann schoen machen, wenn der user OK klickt
Die Frage bei get/set ist doch auch immer: muss man wirklich auf die Elemente zugreifen?
reicht es nicht, wenn die Klasse sich selber darstellen kann? zB indem sie eine const struct liefert, in der alle Daten enthalten - so haettest du eine get Methode, die die kapselung nicht bricht Und um damit die Daten in einem Dialog auszufuellen reicht es auch.
natuerlich kenne ich das system nicht und kann deshalb nichts mit sicherheit sagen - aber vielleicht findest du eine meiner ideen ja interessant...
ich kenne jemanden der bei einer grossen gearbeitet hat und da hatte die halt pro mitglied halt soviele daten die dann in versch. klassen untergebracht sind.
find ich aber normal.
Eine Klasse fuer Vorname, Nachname, Alter,...? ne, das verstehe ich jetzt nicht.
Natuerlich kann sich eine Klasse anbieten, wenn das Datum komplex ist, zB irgendweclhe beziehungen zu anderen Daten handlen muss.
man nimmt auch keine "einfache struct" für die daten dann, weil man nicht gerade die 0te oder 1ste normalform wählt. deswegen kapselt man immer in eigene klasse wenn sinnvoll
kommt halt immer darauf an was man will. eine klasse ist nicht immer die beste wahl.
als 'rule of thumb' kann man sagen, dass eine klasse die alle ihre member per get/set veroeffentlicht, uU besser eine struct ist. (Ausnahmen gibt es natuerlich immer).
Kunde, Verkäufer, Person, adresse, bank, artikel, einkauf, einkaufartikel, usw. dies alles in einer "einfachen" struct zu modelieren? davon wird dir jeder db designer abraten.
adresse waere zB ein Kandidat fuer eine struct. uU auch artikel - haengt aber mit der modellierung zusammen.
ich glaube du verstehst mich nicht: ich sage nicht: nimm immer struct, sondern nimm nicht immer klassen nur weil es sie gibt.
muss ja nicht immer die string klasse sein, die sich "nur" mit strings beschäftigt.
natuerlich. aber zB eine Klasse fuer Adressen wo du
setStreet, setHouseNr, setCity, setZIP, etc. hast - was bringen sich dann die set Methoden, wenn die eh nicht auf plauibilitaet pruefen koennen (hoechstens city und ZIP, aber selbst das kann zu aufwaendig werden).
