Basics: Auf Felder einer Klasse zugreifen

[PeterPanino]

In verschiedenen Anleitungen zur objektorientierten Programmierung wird immer wieder davor gewarnt, direkt auf die Felder einer Klasse zuzugreifen. Der Grund dafür wird aber nie rational und ausführlich dargestellt. Während dies bei komplexeren Klassen, die Funktionen und Methoden zur Manipulation der Feldwerte enthalten, verständlich ist, erscheint dies bei sehr einfachen Klassen, die nur ein paar einfache Felder enthalten, nicht einleuchtend. Wieso sollte ich bei dem folgenden Klassen-Beispiel Getter und Setter implementieren?

Delphi-Quellcode:

TMyClass = class
  FEinByte: Byte;
  FEinString: string;
end;

[DeddyH]

Natürlich hast Du Recht, wenn Du es nicht brauchst, musst Du es nicht machen. Allerdings sollte man es sich gleich angewöhnen, Getter- und Setter-Methoden zu implementieren, das ist
1. besserer Stil
2. schneller zu implementieren, wenn man später doch Einfluss darauf nehmen möchte, was gesetzt/gelesen werden darf.

Also besser gleich von Anfang an richtig machen, dann muss man sich später nicht ärgern/umgewöhnen ;)

[mkinzler]

In Delphi kannst du auch eine Property anlegen und hast dann die Vorteile von beidem.

[DeddyH]

Naja, nur mit einer Property ist es aber auch nicht getan, finde ich.

[mkinzler]

Natürlich in Verbindung mit (Getter/)Setter

Delphi-Quellcode:

TMyClass = class
private
  FEinByte: Byte;
public
  Procedure setEinByte( Value: byte);
published
  property EinByte: Byte read FEinByte write setEinByte;
end;

[DeddyH]

In Ordnung, dann sind wir und einig ;)

[PeterPanino]

Zitat:

Zitat von mkinzler

Natürlich in Verbindung mit (Getter/)Setter

Delphi-Quellcode:

TMyClass = class
private
  FEinByte: Byte;
public
  Procedure setEinByte( Value: byte);
published
  property EinByte: Byte read FEinByte write setEinByte;
end;

Sollte die Sichtbarkeit von setEinByte nicht private sein?

[DeddyH]

Ja

[Andreas H.]

Hallo,

Zitat:

Zitat von mkinzler

Delphi-Quellcode:

public
  Procedure setEinByte( Value: byte);

hm, ich hätte hier zunächst private favorisiert.

Ich mache es auch immer mit Properties!

Andreas

<zu langsam :roll: >

[mkinzler]

Zitat:

Sollte die Sichtbarkeit von setEinByte nicht private sein?

Bei reiner Verwendung durch die Property würde die Sichtbarkeit privat natürlich reichen. wenn man den Setter aber public deklariert kann man diesen auch alternativ aufrufen ( ist in anderen OOP-Sprachen ja so)

[PeterPanino]

Zitat:

Zitat von mkinzler

Zitat:

Sollte die Sichtbarkeit von setEinByte nicht private sein?

Bei reiner Verwendung durch die Property würde die Sichtbarkeit privat natürlich reichen. wenn man den Setter aber public deklariert kann man diesen auch alternativ aufrufen ( ist in anderen OOP-Sprachen ja so)

Wieso sollte man den Setter von außerhalb einer Klasse aufrufen wollen, wenn man die Property hat?

[mkinzler]

Zitat:

Wieso sollte man den Setter von außerhalb einer Klasse aufrufen wollen, wenn man die Property hat?

Du wirst ja nicht dazu gezwungen, den Setter zu nehmen. ist ja alternativ. Ich deklariere meine Properties halt public andere halt privat. Ich sehe jetzt hier keinen Grund hier eine OT-Grundlagendiskussion zu führen.

[PeterPanino]

Kennt jemand ein gutes Lernprogramm (Website, PDF, eBook o.ä.), das nicht nur die Grammatik der objektorientierten Programmierung mit Delphi lexikalisch erklärt, sondern wo Beispiele der objektorientierten Programmierung als Umsetzung von Erfordernissen der täglichen Programmierpraxis dargestellt werden?

[Luckie]

Guck mal hier: http://delphitutorials.michael-puff.de

[OregonGhost]

Als kleine Ergänzung: Auch wenn oft empfohlen wird, vom Konzept der Kapselung, das ja zentral für OOP ist, nie abzurücken, so ist es doch nicht ganz selten, besonders in der C/C++-Welt, so genannte PODs (Plain Old Data Types) nur mit öffentlichen Feldern auszustatten und komplett ohne Zugriffsmethoden. In Delphi verwendet man für diese typischerweise keine Klassen, sondern records. In anderen Sprachen ist die Trennung aber nicht so streng, in C++ zum Beispiel liegt der einzige Unterschied zwischen den Typen class und struct, die eigentlich class und record in Delphi entsprechen, in der unterschiedlichen Default-Sichtbarkeit von Elementen (private für class, public für struct).

In Delphi ist es also praktisch gesehen so: Wenn du öffentliche Felder haben willst, der Datentyp also wirklich nichts anderes machen soll als Daten aufzunehmen, nimm einen Record mit Feldern; wenn du kapseln willst, der Datentyp also seine tatsächlichen Datenstrukturen vor dem Benutzer verstecken soll, eine Klasse mit Eigenschaften. Beide Möglichkeiten sind für sich genommen nicht die endgültige Antwort auf alle Fragen.

Die Tatsache, dass ein Typ eine Klasse oder ein Record ist, macht direkt deutlich, wofür er gedacht ist, und diese Trennung ist sehr sinnvoll. Leider hat man häufig genug Typen, die eigentlich PODs sind, aber trotzdem ein paar Zugriffsmethoden für leichtere Verwendung haben sollen. In Delphi bist du dann im Prinzip gezwungen (zumindest früher, da hatte sich ja auch mal was geändert), daraus eine Klasse zu machen. In so einem Fall ist das aber auch völlig ok und da musst du dir keine Sorgen machen, dass dein Code-Stil schlecht ist.