Zitat von
idefix2:
Ja, wenn ich einen Getter oder Setter brauche, macht das ganze natürlich Sinn. Aber das könnte ich ja bei Bedarf immer noch machen, wenn sich herausstellt dass ich es brauche. Meine Frage ist konkret: Spricht etwas dagegen, direkt eine Variable als public zu erklären, solange ich weder zum Setzen noch zum Lesen des Werts eine Methode benötige? Gibt es vielleicht Probleme bei einer abgeleiteten Klasse, wenn ich dann dort eine Methode zum Setzen oder zum Lesen dieser Variable brauche?
Hi,
das kommt drauf an, ob Du die Klasse sicher machen möchtest oder nicht. Sicher in der Hinsicht, dass Du eine Kontrolle darüber hast, was bei dem Zugriff auf die Variable passiert... Ok, wenn nur Du selbst an Deinem Programm rum baust, macht das keinen großen Unterschied, da Du selber wissen solltest, was Du da macht. Aber wehe, Dein Programm wird größer und Du übersiehst den direkten, ungesteuerten Zugriff auf eine Variable, kann das Ärger geben, vor allem, wenn mehrere am Projekt arbeiten.
Außerdem ist es ja Sinn und Zweck in der
OOP den Zugriff auf Variablen, oder besser Eigenschaften nicht einfach public zu machen, sondern dies gesteuert (gekapselt) ablaufen zu lassen. Dazu ein Beispiel, was oben noch garnicht erwähnt wurde: direkter Zugriff und Getter-/Setterfunktionen mixen:
Delphi-Quellcode:
TUnfug = class
private
FDummerspruch: String
public
procedure SetDummerspruch(Spruch: String);
property Dummerspruch: String read FDummerspruch write SetDummerspruch;
end;
So wäre zumindest möglich, im Setter zu prüfen, ob der übergebene Wert überhaupt Sinn macht...
VG Pixfreak
Edit: Vor allem wenn man eine ältere Klasse hat und diese erweitert, bin ich mit dem getrennten Zugriff immer auf der sicheren Seite und brauche nicht den ganzen Code nach eventuellen Zugriff auf public Variablen absuchen und ich kann das Interface zu jeder Zeit ändern, ohne Änderung nach außen...