Ist eine Klasse ohne Methoden OOP-Konform?

[dragi]

Hallo,

ich baue gerade aus Lust und Laune eine Adressverwaltung die komplett OOP befolgen soll. Jetzt habe ich eine Klasse Person die aber keine Methoden hat sondern nur die Attribute Name, Vorname, Strasse, PLZ, Ort. Ist das jetzt trotzdem nach OOP eine Klasse? Ich wüsste nicht welche Methoden diese Klasse haben sollte da das erzeugte Objekt ja nur einen Datensatz repräsentiert.

Vielen Dank für eure Antwort

Dragi

[Luckie]

Natürlich ist das noch OOP konform. Aber warum gehst du nicht auch den letzten Schritt und fügst Methoden zum Verwalten der Daten hinzu? Wie zum Beispiel Methodeen zum Speichern, Laden, Ausgeben, ...

[dragi]

@Luckie

was meinst du genau? Ich habe eine Klasse die das schreiben und lesen in die Datenbank übernimmt. Oder meinst du die Bildschirmausgabe?

Gruß

Dragi

[tommie-lie]

Üblicherweise gehören zu den Attributen mindestens noch Setter, die die übergebenen Daten auf Korrektheit prüfen und gegebenenfalls irgendwelche Umformungen vornehmen.
Aber schon allein weil du von TObject ableiten musst, hast du Methoden, obgleich auch eine methodenlose Klasse, wie Luckie schon sagte, immer noch eine stinknormale Klasse ist.

[hanselmansel]

HiHo,

du implementiert eine Methode "SetName". Diese überprüft das übergebene Argument zum Beispiel darauf, ob der string leer ist, oder zahlen enthält. Beides wäre für Namen ja ziemlich außergewöhnlich. Am ende wird dann evtl. der Parameter in das Feld "Name" geschrieben.

MfG,

hanselmansel

[dragi]

Das hab ich verstanden und mit den Settern macht das auch Sinn.

Vielen Dank

Dragi

[Chewie]

Bei Delphi hast du ja die Möglichkeit, diese Setter nach auén zu verstecken und den Zugriff ins Properties zu kapseln. Nach außen hin wird dann auch keine Methode aufgerufen.

[tommie-lie]

Zitat von Chewie:

Bei Delphi hast du ja die Möglichkeit, diese Setter nach auén zu verstecken und den Zugriff ins Properties zu kapseln.

Hm, ich denke, wenn er sich mehrere Klassen schreibt und sich Gedanken darüber macht, ob man seinen Code noch objektorientiert nennen kann, wird er auch wissen, daß es in Delphi Properties gibt und wie man sie richtig anwendet

Zitat von dragi:

Ich habe eine Klasse die das schreiben und lesen in die Datenbank übernimmt.

Klingt so, als sei diese Klasse darauf angewiesen, daß man ihr die Personen-Objekte gibt. Sinn von Objektorientierung ist unter anderem Code-Reusing, und was du da hast klingt für mich wenig reusable. Wenn du später deine Personen-Klasse änderst, müsste ja auch die Datenbank-Klasse geändert werden. Ich habe es bisher immer so gehalten, daß ich Datenanbindungen so abstrakt wie möglich gestalte und das eigentliche Verwalten in die Datenklassen auslagere, sodaß diese sich selbst verwalten können. Bei dir würde das bedeuten, daß ich eine Datenbank-Klasse mit einer Methode "GetRecord" hätte, die mir in einer fest definierten Form einen Datensatz aus der Datenbank besorgt und mir Zugriff auf die einzelnen Felder des Datensatzes erlaubt. In der Personen-Klasse würde ich dann auf diese Weise auf die Datenbank zugreifen und klassenintern die Daten auswerten. Das hat den Vorteil, daß ich meine Datenanbindung nicht verändern muss, nur weil sich meine Daten verändert haben, die liest nur stupide etwas aus der Datenbank und legt die Felder frei, und daß ich das gesamte Datenbackend austauschen kann. Gefällt mir meine Datenbank nicht mehr und möchte ich auf XML umsteigen, schreibe ich meine Datenanbindung neu, baue das alte Interface nach, für den Rest der Anwendung geschieht das somit transparent, und nach einem Neukompilieren läuft alles mit XML. Des weiteren bleibt meine Datenanbindung wiederverwertbar in einem späteren Projekt, denn da die Daten egal sind, muss ich mir die datenanbindung nicht nochmal neu schreiben, wenn ich statt Personen plötzlich Waren oder Abrechnungen verwalten will.
Sollten meine Mutmaßungen über deine Klassenhierarchie falsch sein, vergiss einfach, was ich gerade sagte