C++ Klasse

SeanRenard

Cadet 4th Year
Registriert
Aug. 2015
Beiträge
87
Hey Leute
Ich sitze gerade vor C++ -Thema Klasse und verstehe eigentlich nicht so viel ...
Im Unterricht müssen wir mit Klassen eine Aufgabe schreiben, die folgendermaßen aussieht: Man hat eine Klasse mit Name, Vorname, Kontonummer und Kontostand. Der Kunde (den man eintragen muss) hat Schulden (122 Euro), die man begleichen muss... Also begleicht man sie im cmd. Am Ende werden die Daten angezeigt....

Könnt ihr mir bitte erklären wie, wo und was man machen muss? Habe schon die Funktionen erstellt:
c1.PNGc2.PNGc3.PNGc4.PNGc5.PNGc6.PNG


Mit freundlichen Grüßen
Sean
 
Du kannst mithilfe von

HTML:
[CODE][/CODE]

auch Quelltext posten.
 
Die Funktionen sind selbsterklärend.

Ein Objekt der Klasse erstellen mit Name, Kundennummer etc. und dann verschiedene Methoden anwenden.

GetKundenNummer zeigt dir z.B. die Kundennummer an, vereinfacht gesagt ->
Code:
cout << Kundennummer;
 
1. Objekt mit leeren Attributen erstellen.
2. Mit den Settern Attribute vergeben.
3. Mit Gettern Attribute ausgeben.
 
Warum setdings-Methoden benutzen, wenn sie nur ein umständlicher Weg sind, den Zuweisungsoperator zu schreiben? Ist das Selbstzweck, oder hat es irgendeinen praktischen Sinn?
 
Wenn eine Klasse für jedes Attribut einen Setter hat, der nichts weiter tut als dem gleichnamigen Attribut den entsprechenden Wert zuzuweisen, dann ist mit hoher Wahrscheinlichkeit das Design scheiße. Das hat dann nicht mehr viel mit Encapsulation und noch weniger mit Abstraktion zu tun, das ist die aus Java und dessen JavaBeans bekannte und gehasste Setter- und Getteritis.

Gut, ich habe die Aufgabe nicht gestellt, aber CKunde wäre bei mir mit großer Wahrscheinlichkeit immutable.

Was gewinnt man dadurch, die Kundennummer ändern zu können? Wahrscheinlich gar nichts.
Was verliert man? Die Möglichkeit, die Kundennummer als Index für Kunden-Objekte in einer entsprechenden Datenstruktur (Map) zu benutzen.
 
Zuletzt bearbeitet:
Das meine ich nicht. Eine private-Variable, auf die man per get und set direkt zugreifen kann, ist praktisch nichts anderes als eine public-Variable mit verkorkster Syntax und je einem unnötigen Funktionsaufruf sowie Code für zwei völlig triviale Methoden. Frage mich also: was soll das?
 
Zuletzt bearbeitet:
VikingGe schrieb:
Wenn eine Klasse für jedes Attribut einen Setter hat, der nichts weiter tut als dem gleichnamigen Attribut den entsprechenden Wert zuzuweisen, dann ist mit hoher Wahrscheinlichkeit das Design scheiße.

Wenn die Klasse veränderlichen Zustand zulässt (nicht immutable ist) und das Attribut veränderlich sein soll, dann ist das völlig ok.

Immutabilität ist eine völlig andere Baustelle, die dir nicht dabei hilft, Implementierungsdetails zu verbergen. Dort hast du bei gutem Design wenigstens immernoch getter.

edit:

asdfman schrieb:
Frage mich also: was soll das?

Beispiel: Nenne mal die Variable vorname in firstname um, ohne dadurch Client-Code kaputt zu machen.
 
Zuletzt bearbeitet:
Ändere doch in C++ irgendwas im private-Block, ohne jeden Code, der die Klasse verwendet, neu kompilieren zu müssen.

Damit allein kommst du um das Problem nicht herum. Dann musst du so oder so zusätzlichen Aufwand treiben.
 
Dort hast du bei gutem Design wenigstens immernoch getter.
Richtig. Aber das ist kein wie von asdfman treffend beschriebener Wrapper mehr, der ein private-Attribut zu 100% public macht.

Implementierungsdetails verstecke ich durch Setter und Getter auch nicht. Attribute sind Implementierungsdetails. Bei einer Klasse, die rein der Datenhaltung dient (...was hier offensichtlich der Fall ist), ist das ja auch völlig okay und nicht wirklich vermeidbar. Aber dann bitte möglichst immutable, v.a. wenn die Objekte so klein sind. Oder überlegen, ob ein C-Style-struct nicht möglicherweise doch die bessere Lösung ist.
 
asdfman schrieb:
Ändere doch in C++ irgendwas im private-Block, ohne jeden Code, der die Klasse verwendet, neu kompilieren zu müssen.

Wie meinen?

VikingGe schrieb:
Implementierungsdetails verstecke ich durch Setter und Getter auch nicht. Attribute sind Implementierungsdetails.

Attribute sind Implementierungsdetails, und diese verberge ich mit gettern und settern (falls mutable). Wo sind diese nun nicht versteckt?
 
Zuletzt bearbeitet:
Wenn ich über Setter und Getter direkten Zugriff auf Attribute habe, habe ich Zugriff auf Implementierungsdetails. Was ist daran versteckt?
 
crvn075 schrieb:
Meinen so wie sagte ich tun.

Privateblock ändern bedeutet Header ändern. Header ändern bedeutet, dass jede Datei, die den Header per #include (oder #include eines #includes etc.) einzieht neu kompiliert werden muss.
Das kann man zwar umschiffen, aber das sagte ich ja auch.
 
VikingGe schrieb:
Wenn ich über Setter und Getter direkten Zugriff auf Attribute habe, habe ich Zugriff auf Implementierungsdetails. Was ist daran versteckt?

Nein. Du hast Zugriff auf Getter und Setter, die eine Schnittstelle zu der Klasse bilden und dir Daten Zugänglich machen. In welcher Form diese woher kommen ist von außen nicht ersichtlich. Vielleicht hat die Klasse tatsächlich ein vorname-Attribut, vielleicht aber auch nicht. Du weißt nur, dass du über getVorname den Vornamen bekommst.

Vielleicht wird später mal entschieden, Vor- und Nachnamen zusammen in einem String abzuspeichern (Implementierungsdetail), beispielsweise durch ein Sonderzeichen getrennt. Setter und Getter müssen den String dann zusammenführen bzw. auseinandernehmen, aber von außen betrachtet hat sich rein gar nichts verändert.


asdfman schrieb:
Privateblock ändern bedeutet Header ändern. Header ändern bedeutet, dass jede Datei, die den Header per #include (oder #include eines #includes etc.) einzieht neu kompiliert werden muss.
Das kann man zwar umschiffen, aber das sagte ich ja auch.

Das hab ich schon geblickt, aber ich wollte nicht glauben, dass du so einen Äpfel- und Birnen Vergleich daherbringst. Für dich ist Neukompilieren also das gleiche wie (aus Clientsicht) Änderungen auf Codeebene machen zu müssen, die potentiell an zig Stellen auftreten können, Fehlerquelle sein können, es vielleicht nötig machen, eine geupdatete Doku zu lesen? Na dann..
 
Beispiel: Nenne mal die Variable vorname in firstname um, ohne dadurch Client-Code kaputt zu machen.

Für dich ist Neukompilieren also das gleiche wie (aus Clientsicht) Änderungen auf Codeebene machen zu müssen, die potentiell an zig Stellen auftreten können, Fehlerquelle sein können, es vielleicht nötig machen, eine geupdatete Doku zu lesen? Na dann..

Mir Dinge zu unterstellen, die ich nie gesagt habe und gleichzeitig deine eigene Behauptung zu revidieren, ist keine faire Art, sich zu unterhalten.
 
VikingGe schrieb:
Gut, ich habe die Aufgabe nicht gestellt, aber CKunde wäre bei mir mit großer Wahrscheinlichkeit immutable.

Was gewinnt man dadurch, die Kundennummer ändern zu können? Wahrscheinlich gar nichts.
Was verliert man? Die Möglichkeit, die Kundennummer als Index für Kunden-Objekte in einer entsprechenden Datenstruktur (Map) zu benutzen.

Die CKunde-Klasse an sich würde ich nicht unbedint immutable machen. Die Kundennummer sollte schon konstant sein. Irgendeinen unveränderlichen, eindeutigen Schlüssel muß es ja geben. Aber Der Kunde könnte z.B. zum Standesamt laufen und seinen Namen ändern lassen. Dann wär's doch einfacher, wenn man bei CKunde den Namen auch ändern könnte. :) Als Schlüssel für maps würde ich dann eben nicht CKunde sondern bloß die Kundenummer verwenden.
 
Zurück
Oben