Basics: Auf Felder einer Klasse zugreifen

[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.