Klassen Methoden die private stehen

[Back2Code]

Ich bin gerade dabei mir nochmal das Thema OOP genauer anzusehen und bin dabei auf folgendes Code Beispiel von Popov aus einem anderen Thread gestoßen:

Delphi-Quellcode:

type
  TZitrone = class
  private
    FZitronenfarbe: String;
    procedure ZFarbe(a: String);
  public
    constructor Create;
    property Zitronenfarbe: string read FZitronenfarbe write ZFarbe;
  end;

constructor TZitrone.Create;
begin
  FZitronenfarbe := 'gelb';
end;

procedure TZitrone.ZFarbe(a: String);
begin
  if (LowerCase(a) = 'grün') or (LowerCase(a) = 'gelb') then
    FZitronenfarbe := a
  else
    FZitronenfarbe := 'gelb';
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  Zitrone: TZitrone;
begin
  Zitrone := TZitrone.Create;
  Zitrone.Zitronenfarbe := 'blau';
  ShowMessage(Zitrone.Zitronenfarbe);
  Zitrone.Free;
end;

Ansich verständlich und gut lesbar dennoch ist jetzt für mich nicht ganz ersichtlich für was man genau die Methode TZitrone.ZFarbe benötigt und wann/wie diese aufgerufen wird. :oops:

Meine Vermutung ist, dass der Aufruf passiert sobald ich dem public property Zitronenfarbe etwas zuweise..Würde gerne meine Theorie bestätigt haben bzw. die richtige Lösung dazu.

Wann benutzt man genau Propertys?
Wie sind die Einsatzmöglichkeiten?

[p80286]

Da bist Du schon auf dem richtigen Weg.
In der Klasse sind Werte gespeichert (FZitronenfarbe)
Auf diese Werte kannst Du direkt zugreifen, was aber nicht dem Sinn der Kapselung entspricht. Dafür ist dann die Property mit den Getter- und Setter-Methoden zuständig. In Popovs Beispiel also die Zitronenfarbe.
In diesem Beispiel wird die gespeicherte Farbe ausgelesen wie sie ist und bei eier Wertzuweisung wird dieser ggf. modifiziert (ZFarbe).

In der Praxis kann man das z.B. anwenden um die obere und untere Grenze eines Arrays nicht zu unter bzw. überschreiten oder einen zweiten wert zu schreiben oder....



Gruß
K-H

[DeddyH]

Wie Du schon richtig bemerkt hast, handelt es sich um einen sog. Setter für die Property Zitronenfarbe (übrigens sollte er nach üblicher Nomenklatur besser SetZitronenfarbe heißen). Properties benutzt man, wenn eine Klasse Zugriff auf bestimmte Felder zur Verfügung stellen soll. Man könnte das theoretisch auch einfach so lösen, dass man das entsprechende Feld in den public-Abschnitt schreibt, aber dann hat die Klasse keinerlei Kontrolle über das Feld. Properties können darüber hinaus auch ReadOnly oder WriteOnly deklariert werden, was mit Feldern direkt nicht möglich ist. Zu guter Letzt kann es auch sein, dass es gar kein entsprechendes Feld in der Klasse gibt, sondern die (ReadOnly-)Property einen Rückgabewert einer Funktion repräsentiert. Das alles ist für den Benutzer der Klasse nicht relevant, da er lediglich auf die Properties zugreift und die Iterna nicht kennen muss.

[mkinzler]

Zitat:

Zitat von Back2Code (Beitrag 1249987)

--
Ansich verständlich und gut lesbar dennoch ist jetzt für mich nicht ganz ersichtlich für was man genau die Methode TZitrone.ZFarbe benötigt und wann/wie diese aufgerufen wird. :oops:

Meine Vermutung ist, dass der Aufruf passiert sobald ich dem public property Zitronenfarbe etwas zuweise..Würde gerne meine Theorie bestätigt haben bzw. die richtige Lösung dazu.

Ja. Steht hier:
property Zitronenfarbe: string read FZitronenfarbe write ZFarbe;
Der Code sagt aus, dass bei Änderung des Wertes (write) diese Methode aufgerufen wird.
[QUOTE]Wann benutzt man genau Propertys? Properties sind "virtuelle" Eigenschaften, welche im späteren Code nicht mehr vorhanden sind.

Zitat:

Wie sind die Einsatzmöglichkeiten?

Properties stellen sicher, dass man den Vorteil öffentlicher Eigenschaften (Attribute) hat und trotzdem information hiding implementieren kann.
Denn die eigentlichen Eigenschaften sind ja privat. Der eigentliche Typ kann von dem der Properties abweichen oder es gibt gar keine Eigenschaften hierfür.

[Aurelius]

Meine Vorredner haben vollkommen recht. :thumb:

Um das Beispiel nochmal genauer zu erklären:

Delphi-Quellcode:

procedure TZitrone.ZFarbe(a: String);
begin
  if (LowerCase(a) = 'grün') or (LowerCase(a) = 'gelb') then
    FZitronenfarbe := a
  else
    FZitronenfarbe := 'gelb';
end;

Diese Prozedur lässt also nur grün und gelb als Farbe zu. Dadurch kann man die Eingabe von unsinnigen Werten (z.B. blau) oder Fehlereingaben verhindern. Netürlich kann man innerhalb der Prozeduren alle möglichen Dinge machen: Berechnungen, Loging etc. pp.

[himitsu]

Zitat:

Delphi-Quellcode:

procedure TZitrone.ZFarbe(a: String);
begin
  if (LowerCase(a) = 'grün') or (LowerCase(a) = 'gelb') then
    FZitronenfarbe := a
  else
    FZitronenfarbe := 'gelb';
end;

Wobei man sich hier noch überlegen kann, ob es nich besser wäre einen Fehler zu werfen
oder still und heimlich einen "Standardwert" zu setzen (so wie es aktuell gemacht wird)
oder den aktuellen Wert in diesem Fall garnicht zu ändern.

Delphi-Quellcode:

procedure TZitrone.ZFarbe(a: String);
begin
  if MatchText(a, ['grün', 'gelb']) then  // if (LowerCase(a) = 'grün') or (LowerCase(a) = 'gelb') then
    FZitronenfarbe := a
  else
    raise Exception.CreateFmt('Die Farbe "%s" ist nicht erlaubt.', [a]);
end;

Delphi-Quellcode:

procedure TZitrone.ZFarbe(a: String);
begin
  if MatchText(a, ['grün', 'gelb']) then
    FZitronenfarbe := a;
end;

PS: LowerCase ist eine uralte "schnelle"/einfache Funktion und unterstützt nur ASCII, also keine Ä, Ö und Ü.
Hier sollte man besser AnsiLowerCase verwenden.
Aber nicht Wundern ... irgendwer ist bei der Umstellung auf Unicode (D2009) auf die saublöde Idee gekommen und hat die Unicode-Versionen mit Ansi benannt.
(WideLowerCase geht dafür nur auf den WideString und sollte mit String/UnicodeString besser nicht verwendet werden)

PSS: Bei MatchText ist das Anders, denn dieses ist eine "Umleitung" zur passenden Funktion (hier AnsiMatchText)

[himitsu]

Schade ist auch, daß es bei Strings keinen DefaultWert gibt.

Delphi-Quellcode:

property Zitronenfarbe: string read FZitronenfarbe write SetZitronenfarbe default 'gelb';

Bei der Komponentenentwicklung gibt man damit an, wann ein Published-Porperty in der DFM gespeichert wird. (wenn Wert = Defaultwert, dann nicht)



Und mehr Arbeit hat man eigentlich auch nicht, bei der Verwendung von Properties.
Felder (Komponenten-Variablen) sollten besser nie direkt, sondern praktisch immer nur über ein Property, von außen zugänglich sein.

Delphi-Quellcode:

// geschrieben
  public
    property Zitronenfarbe: string;

// nach Klassenvervolständigung (Strg+Shift+C)
  private
    FZitronenfarbe: string;
    procedure SetZitronenfarbe(const Value: string);
  public
    property Zitronenfarbe: string read FZitronenfarbe write SetZitronenfarbe;



  public
    property Zitronenfarbe: string read FZitronenfarbe write FZitronenfarbe;

  private
    FZitronenfarbe: string;
  public
    property Zitronenfarbe: string read FZitronenfarbe write FZitronenfarbe;



// nur hier gibt es ein Problem, denn die Klassenvervollständigung denkt sich "Ein Getter kann nicht schaden" (selbst wenn man wirklich nur ein Write)
  public
    property Zitronenfarbe: string write FZitronenfarbe;

  private
    FZitronenfarbe: string;
  public
    property Zitronenfarbe: string write FZitronenfarbe read FZitronenfarbe;

Es gibt auch Code-Vorlagen, welche ebenfalls die Variablen, Setter und Getter erstellen.
- einfach das CodeWort schreiben und mit Leertaste abschließen
- nur irgendwie geht das beim "prop" nicht, mit der Leertaste (XE3)
- aber wenn man sich die Codevervollständigung (Strg+Leertaste) vor Wortbeginn oder mitten drin anzeigen lässt, dann geht es und man sieht auch, was es sonst noch gibt

prop => property name: type read getter write setter;
propf => property name: type read Fname write Fname;
propgs => property name: type read Getname write Setname;
propro => property name: type read getter;
proprof => property name: type read Fname;

Nur noch geünschten "Name" [enter] "Typ" [enter] eingeben und fertig. (bei anders-namentlichem Getter und Setter diese natürlich auch noch benennen)

weitere Vorlagen siehe MainMenu > Ansicht > Vorlagen

[Furtbichler]

Zitat:

Zitat von DeddyH (Beitrag 1249992)

WriteOnly deklariert werden...

Kein guter Stil

Zitat:

Zitat von DeddyH (Beitrag 1249992)

...übrigens sollte er nach üblicher Nomenklatur besser SetZitronenfarbe heißen

Wieso? Heißt doch so (fast) "SetFarbe" vs. "Z-Farbe" :wall:

[DeddyH]

Guter Stil oder nicht, die Möglichkeit besteht, und nichts anderes habe ich geschrieben.

[himitsu]

Wobei WriteOnly auch Absicht sein kann. (gern zusammen mit einem

Delphi-Quellcode:

stored False

)
Oder Properties, die man setzen, aber nicht auslesen kann. (ja, das gibt es, daß man den/die reingeschriebenen Wert(e) nicht mehr rausbekommt)

Bei uns sind noch ein paar "alte" Property in hunderten DFMs verstreut.
Nicht nur die einkompilierten in der EXE und den vielen DLLs, sondern auch welche als Text-DFM in den Datenbanken der Kunden. (dynamische Forms)

Für die gibt es nur noch aus Kompatibilitätsgründen einen Setter, damit der DFM-Loader nicht knallt und machmal auch im Setter das Umschreiben in den neuen Property.

Im Code werden die nicht mehr verwendet und wenn man doch mal drauf zugreift (was meistens lesend geschieht), dann gibt es einen Compilerfehler.
(beim Setzen der Property kann man Zugriffe im Code auch erkennen, indem man eine Exception im Setter wirft, wenn die Komponente sich nicht mehr im DFM-Lese-Modus/Status befindet)


Und ganz blöde ist, daß es keine Möglichkeit gibt einen Property als

Delphi-Quellcode:

deprecated

zu markieren. (zumindestens im XE)