Klassenmember in separaten Klassen kapseln oder primitiv lassen?

Schlangenmensch

Ich würde für extra Typen votieren. Ich bin leider häufig genug zu faul dafür selbst, aber extra Typen macht den Code leichter zu lesen und sicherer zu nutzen.

Wenn wir uns die erste Klasse angucken, wie würde da ein Ctpr aussehen?

ungefähr so:

Kunde::Kunde(const std::string& straße, const std::string& hausnummer, const std::string& vorname, const std::string& name)

Kunde kunde("teststraße", "42", "Luke", "Skywalker"); //funktioniert
Kunde kunde2("42", "Luke", "Skywalker", "teststraße"); //kompiliert auch

Wenn du eigene Klassen hast, hast du so was:

class Straße{
public:
explicit Straße(const std::string &straße_):
straße(straße_){};

private:
std::string straße;
}

//Für die anderen Parameter was ähnliches

Kunde::Kunde(const Straße& straße, const Hausnummer& hausnummer, const Vorname& vorname, const Name& name)

Kunde kunde(Straße("teststraße"), Hausnummer("42"), Vorname("Luke"), Nachname("Skywalker"));

Kunde kunde2(Vorname("Luke"), Straße("teststraße"), Hausnummer("42"), Nachname("Skywalker")); //Compiler Fehler

Wenn du eigene Typen hast, ist es viel schwerer Parameter zu vertauschen und beim lesen sieht man sofort was welcher Parameter ist. Auch wenn man später irgendwie Funktionen hat, wie zum Beispiel

ValidateStraße(const Straße& straße)

kann man die Funktion wirklich nur auf einer Straße aufrufen und nicht ausversehen auf einem Namen.

Daher wäre ich für eigene Klassen

Das Stichwort für Google wäre "Type safe c++"

Helmut.Jakoby

Was zusätzlich für eine Klasse für die einzelnen Werte spricht, dass ich bei Änderungen der Konditionen wie z.B. Zeichenanzahl oder Struktur der "Strasse" als solches, nicht jede Funktion suchen muss, wo ich diese als std::string übergebe und dort ggf. jedes mal Anpassungen vornehmen muss. Die Parameterübergabe bzw. Verarbeitung einer "Strasse" als Objekt findet sich schneller.

wob

@Schlangenmensch sagte in Klassenmember in separaten Klassen kapseln oder primitiv lassen?:

Ich würde für extra Typen votieren. Ich bin leider häufig genug zu faul dafür selbst, aber extra Typen macht den Code leichter zu lesen und sicherer zu nutzen.

Generell ja, aber der Drawback ist eben manchmal, dass Code sehr aufbläht. Man wird bestimmt irgendwelche Funktionen nutzen wollen, die nur "normale" std::strings (oder gar const char *) als Parameter nehmen. Dann muss man jedes mal sowas wie strasse = Strasse(call_string_style(strasse.to_string())) aufrufen (den Constructor will man dann ja vermutlich explicit haben und keine automatischen casts erlauben). Einerseits ist dann ganz klar, was passiert, andererseits wird es auch manchmal mühsam und es macht nicht immer Sinn, 100% typesafe zu schreiben (insbesondere wenn der Nutzen gering ist - bzw. bei Vertauschungen nicht gleich ein riesiges Problem entsteht).

In diesem Fall will man vielleicht gar nicht explizit Attribute wie "Straße" und "Hausnummer" am Kunden haben, denn das wären eigentlich Attribute von "Adresse". Ein Kunde könnte auch mehrere Adressen haben. Das so zu modellieren, wäre viel wichtiger. Dann übergibt man nämlich einfach immer Adressobjekte anstelle von Straße und Hausnummer separat. Damit ist die Verwechslung dann auch ausgeschlossen (außer beim Erstellen der Adresse). Andererseits wüsste ich aber sowieso nicht, wie man "Name" und "Straße" unterschiedlich validieren könnte. Beide Felder können "wilde Namen" enthalten.

Schlangenmensch

@wob Ja, stimmt schon, Code kann dadurch recht verbose werden. Aber, meiner Meinung nach, übertrifft der Nutzen häufig die größere Schreibarbeit.
Wenn man jetzt öfter Funktionen aufrufen will, die einen String erwartet, dann könnte man mit einem Conversion Operator arbeiten:

class Strasse{
public:
operator std::string() const {return strasse;}
}

Man kann den auch explicit machen, dann muss man aber jedesmal nen static_cast aufrufen. Dafür kann man dann eine Strasse nicht ausversehen zu einem string werden lassen.

wob

@Schlangenmensch sagte in Klassenmember in separaten Klassen kapseln oder primitiv lassen?:

Man kann den auch explicit machen

ja, habe ungefähr auf die Sekunde gleichzeitig zu deinem Kommentar das excplicit oben auch erwähnt. Ich finde immer noch "es kommt darauf an". Bei Datum (!!!), Zahlen, Einheiten etc bin ich voll bei dir. Bei so ein paar Adressstrings? Ich weiß nicht. Halte ich da für übertrieben. Lieber ein schönes Adressobjekt. Und diese automatischen Konvertierungsoperatoren / nicht-explicit Konstruktoren nehmen dann wieder einen Teil der Typsicherheit für Convenience weg.

KK27

@wob sagte in Klassenmember in separaten Klassen kapseln oder primitiv lassen?:

Lieber ein schönes Adressobjekt. Und diese automatischen Konvertierungsoperatoren / nicht-explicit Konstruktoren nehmen dann wieder einen Teil der Typsicherheit für Convenience weg.

Sehe ich genauso. Auf der Arbeit kenne ich selbst viele Stellen in unserem Quellcode, wo solche Cast Operation unbeabsichtigt bzw. teilweise sogar beabsichtigt und nicht sichtbar, passieren. Ich bin immer für Typsicherheit.

@wob sagte in Klassenmember in separaten Klassen kapseln oder primitiv lassen?:

In diesem Fall will man vielleicht gar nicht explizit Attribute wie "Straße" und "Hausnummer" am Kunden haben, denn das wären eigentlich Attribute von "Adresse". Ein Kunde könnte auch mehrere Adressen haben. Das so zu modellieren, wäre viel wichtiger. Dann übergibt man nämlich einfach immer Adressobjekte anstelle von Straße und Hausnummer separat. Damit ist die Verwechslung dann auch ausgeschlossen (außer beim Erstellen der Adresse). Andererseits wüsste ich aber sowieso nicht, wie man "Name" und "Straße" unterschiedlich validieren könnte. Beide Felder können "wilde Namen" enthalten.

Sehe ich genauso, dass ein Kunde natürlich mehrere Adressen haben kann. Das war nur ein einfaches Beispiel. Wenn man es sehr genau nehmen möchte, könnte man natürlich ein komplexes Adressobjekt haben, dass Zugriff auf alle Straßennamen im echten Leben hat und diese validiert.

@Helmut-Jakoby sagte in Klassenmember in separaten Klassen kapseln oder primitiv lassen?:

Was zusätzlich für eine Klasse für die einzelnen Werte spricht, dass ich bei Änderungen der Konditionen wie z.B. Zeichenanzahl oder Struktur der "Strasse" als solches, nicht jede Funktion suchen muss, wo ich diese als std::string übergebe und dort ggf. jedes mal Anpassungen vornehmen muss. Die Parameterübergabe bzw. Verarbeitung einer "Strasse" als Objekt findet sich schneller.

Das ist ein Faktor, den ich noch gar nicht betrachtet und beachtet habe. Ein sehr gut Hinweis.

Tyrdal

Ich würde einfach die member privat machen und die constraints in settern prüfen.

Finnegan

@Tyrdal sagte in Klassenmember in separaten Klassen kapseln oder primitiv lassen?:

Ich würde einfach die member privat machen und die constraints in settern prüfen.

In diesem Fall ja, bei komplexeren Validierungen die man auch an anderen Stellen braucht, kann aber eine eigene Klasse schonmal Sinn machen. Spontan denke ich da z.B. an Validierung gültiger IPv4/v6 Adressen, was man vielleicht an etlichen Stellen im Code benötigt.

P.S.: Wäre das eine Java-Geschäftsanwendung, käme man natürlich nicht um Hilfskonstrukte wie u.a. eine AbstractHausnummerValidationServiceClientFactory herum - da gälte dann eher "eine Bibliothek je Member". SCNR

KK27

@Tyrdal sagte in Klassenmember in separaten Klassen kapseln oder primitiv lassen?:

Ich würde einfach die member privat machen und die constraints in settern prüfen.

Das die Member nicht public sein sollten, ist klar. Du meinst das im Konstruktor die Setter Funktionen aufgerufen werden, die dann gleich validieren?

Tyrdal

@KK27 sagte in Klassenmember in separaten Klassen kapseln oder primitiv lassen?:

@Tyrdal sagte in Klassenmember in separaten Klassen kapseln oder primitiv lassen?:

Ich würde einfach die member privat machen und die constraints in settern prüfen.

Das die Member nicht public sein sollten, ist klar. Du meinst das im Konstruktor die Setter Funktionen aufgerufen werden, die dann gleich validieren?

Ja, das ist so ein Fall wo setter echt Sinn machen, weil sie eben den Wertebereich prüfen können.