Set- und Getter-Methoden

[ThaiSon96]

Hallo,
wir bearbeiten gerade in der Schule das Thema "Klassen". Wir sollen dabei immer Set- und Getter-Methoden benutzen.
Bis jetzt habe ich immer nur Set-Methoden benutzt, die Getter-Methoden habe ich immer weggelassen und es hat dann meistens in Delphi 7 auch geklappt.
Ich habe das jetzt so verstanden, dass man die Set-Methoden braucht, um Werte sozusagen "in die Klasse zu übergeben", damit man dort mit ihnen weiterarbeiten kann.
Liege ich da richtig? Was ist der Sinn hinter den beiden oben genannten Methoden?
Über Antworten würde ich mich freuen.
P.S.: Falls ihr versucht, mir zuhelfen, dann versucht es bitte so vereinfacht wie möglich zu erklären! Danke im Voraus.

[mkinzler]

Das ist Teil des information hiding. Die Eigenschaften sind privat und nur über Getter/Setter zugreifbar.
In Sprachen wie Java wird so etwas praktiziert. Um das RAD Prinzip zu unterstützen, wurde in Delphi die Property eingeführt, wie sich nach aussen als offentliche Eigenschaft zeigt; welche aber "Virtuell" ist.
Die Zugriffe auf diese werden direkt auf die entsprechende private Variable oder auf Getter/Setter umgeleitet.

[Namenloser]

Es geht vor allem darum, eine einheitliche Schnittstelle zu haben.

Zum Beispiel könnte es ja sein, dass der Wert der Variablen nicht direkt im Programm (im Arbeitsspeicher) gespeichert wird, sondern in einer externen Datenbank. Dann würde der Getter den Wert aus der Datenbank laden und der Setter würde den Wert in die Datenbank schreiben.

Es wäre auch möglich, dass man die Art der Speicherung im Nachhinein umbaut – z.B. wurden die Werte zunächst im Arbeitsspeicher gespeichert, und dann später hat man sich dafür entschieden, eine Datenbank zu verwenden. Dann muss man den Code nur an der entsprechenden Stelle anpassen und nicht jede Stelle im Programm, wo auf diese Eigenschaft zugegriffen wurde.

Außerdem hat ein Setter den Vorteil, dass man weitere Aktionen ausführen kann. Hat man z.B. einen Button mit der Eigenschaft „Farbe“, dann kann man beim Setzen der Farbe auch gleich noch ein Neuzeichnen des Buttons anstoßen.

Allerdings gibt es unter Delphi ein wesentlich eleganteres Konzept als Getter und Setter, und zwar Properties. In Fällen, wo Getter und Setter sowieso nur aus Einzeilern bestehen würden, die den Wert einer Variablen zurückliefern oder setzen, kann man sie gleich komplett weglassen und bläht sich so den Code nicht unnötig auf. Außerdem sieht der Zugriff auf eine Property genau so aus wie der Zugriff auf eine normale Variable, was stilistisch schöner ist (aber wohl auch Geschmackssache).

[ThaiSon96]

Danke für die Antworten!
@Namenloser: Kannst du eventuell ein Beispiel für diese Methoden anhand deines Beispiels mit der Datenbank schicken? Das wäre sehr hilfreich! :-D

[Namenloser]

Ein konkretes Code-Beispiel hab ich leider nicht. Da musst du deine Fantasie einsetzen :wink:

[Sir Rufo]

Zitat:

Zitat von ThaiSon96 (Beitrag 1259207)

Danke für die Antworten!
@Namenloser: Kannst du eventuell ein Beispiel für diese Methoden anhand deines Beispiels mit der Datenbank schicken? Das wäre sehr hilfreich! :-D

Schreib du doch mal ein Beispiel und was du dort erklärt haben möchtest, das wäre auch sehr hilfreich ;)

[Perlsau]

Zitat:

Zitat von ThaiSon96 (Beitrag 1259207)

... ein Beispiel für diese Methoden anhand deines Beispiels mit der Datenbank schicken? Das wäre sehr hilfreich! :-D

Beispiel für ein Property, das gelesen und geschrieben werden kann:

Delphi-Quellcode:

UNIT UnitData;

INTERFACE

USES
  SysUtils, Classes, DB, ADODB;

TYPE
  TDatMod = CLASS(TDataModule)
    AConMain     : TADOConnection;

  PRIVATE { Private-Deklarationen }
    fPfadMain : String;

    Function  GetfPadMain: String;
    Procedure SetfPfadMain(const Value: String);

  PUBLIC  { Public-Deklarationen  }

    Property PfadMain : String Read GetfPadMain Write SetfPfadMain;
END;

VAR
  DatMod : TDatMod;

IMPLEMENTATION
{$R *.dfm}
{ TDatMod }

// *************** PRIVATE METHODEN ******************

// ---------- PFADMAIN - GET -------------------------
Function TDatMod.GetfPadMain: String;
begin
  Result := fPfadMain;
end;

// ---------- PFADMAIN - SET -------------------------
Procedure TDatMod.SetfPfadMain(const Value: String);
begin
  fPfadMain := Value;
end;

// *************** PUBLIC METHODEN *******************

// *************** ERGEIGNISSE ***********************

end.

[himitsu]

Man kann das auch für Weiterleitungen nutzen.
z.B. in einer untergeordneten Komponente werden die Daten eigentlich gespeichert, aber im parent gibt es dennoch ein Property, um direkt darauf zuzugreifen.

Oder man erstellt den Rückgabewert erst im Getter.

z.B.

Delphi-Quellcode:

property Uhrzeit: TTime read GetTime;

Oder das Property LineBreak der TStringList. Dieses hat standardmäßig keinen Wert und gibt nur den Inhalt der globalen Konstante SLineBreak zurück.
Erst wenn man etwas zuweist (Setter), dann existiert der "private" Wert, welcher nun zurückgegeben wird.

[bernau]

Zitat:

Zitat von himitsu (Beitrag 1259259)

Oder man erstellt den Rückgabewert erst im Getter.

z.B.

Delphi-Quellcode:

property Uhrzeit: TTime read GetTime;

Will jetzt nicht die Diskussion in eine andere Richtung leiten, aber es interessiert mich einfach.

Was für ein Sinn mach ein Property ohne Setter. Dann kann ich doch gleich eine Function daraus machen.

[Jumpy]

Zitat:

Zitat von bernau (Beitrag 1259264)

Was für ein Sinn mach ein Property ohne Setter. Dann kann ich doch gleich eine Function daraus machen.

Das kann z.B. für lazy initialisation (heißt das so?) interessant sein:

Delphi-Quellcode:

Type TFoo=Class
  private
    fBar:TBar;
    function getBar:TBar;
  public
    Property Bar:TBar read getBar;
  end;

//....

function TFoo.getBar:TBar;
begin
  if fBar=nil then
    begin
    fBar:=TBAr.create;
    //...
    end;
  Result:=fBar;
end;