AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Allgemeines zu Klassen / Objekten

Ein Thema von Luckie · begonnen am 26. Feb 2003 · letzter Beitrag vom 26. Feb 2003
 
Benutzerbild von sakura
sakura

Registriert seit: 10. Jun 2002
Ort: Unterhaching
11.420 Beiträge
 
Delphi 12 Athens
 
#4
  Alt 26. Feb 2003, 13:29
Erst mal schnell: im obigen Beitrag habe ich im Code noch einen kleinen Fehler korrigiert

Delphi-Quellcode:
type TFooClass = class
  private
    FFooCaption : string;
    procedure SetFooCaption(const Value: string);
    function GetFooCaptionEx: string;
  public
    constructor Create;
    property FooCaption: string read FFooCaption write SetFooCaption;
    // kleiner fehler korriegert (Ex am Ende vergessen)
    property FooCaptionEx: string read GetFooCaptionEx;
  end;

constructor TFooClass.Create;
begin
  inherited;
  FFooCaption := 'Default';
end;

procedure TFooClass.SetFooCaption(const Value: string);
begin
  if FFooCaption <> Value then
  begin
    // überprüfen, ob der wert "ok" ist
    if Trim(Value) = 'then
      raise Excpetion.Create('FooCaption muss einen nicht-leeren String enthalten');
    FFooCaption := Trim(Value);
  end;
end;

function TFooClass.GetFooCaptionEx: string;
begin
  Result := Format('Die FooCatpion ist "%s".', [FooCaption]);
end;
So würde das erst einmal bei mir aussehen. In Create greife ich direkt auf die Variable FFooCaption zu, da der Wert eh konstant ist und somit keiner Überrpüfung bedarf. Wenn ich die Regeln ändere muss ich allerdings manuell überprüfen, ob der konstante Startwert immer noch den Bedingungen entspricht

Wenn die Eigenschaft FooCaption gesetzt wird, dann überprüft die Funktion jetzt, ob der neue Wert auch alle Regeln entspricht. Hier könnte auch noch andere Routinen (z.B. Neu Zeichen :: TControl.Invalidate) und Ereignishandler (TOnEmptyValue) vorkommen.

In der Funktion GetFooCaptionEx greife ich dann auf FooCaption und nicht auf FFooCaption zurück. In der aktuellen Lösung ist das zwar genau das Gleiche, falls sich die Implementation jedoch mal ändern sollte, so das vor der Rückgabe von FooCaption noch eine Methode ausgeführt wird, dann stimmt es auch nach der Änderung der Implementation sofort.

Property vs. Funktionen
Da gibt es nicht viel zu sagen, ausser dass es wahrscheinlich schneller zu tippen geht, wenn ich immer nur Object.FooCaption für setzen/auslesen schreiben muss, anstatt von Object.GetFooCaption für das Lesen und Object.SetFooCaption(...) für das Schreiben. Es ist einfach "schöner". Ausserdem macht es anderen Entwicklern den Umgang mit Deinen Objekten leichter.

Noch kurz zu der Frage, wie Du die FooCaptionEx erhälst:
Delphi-Quellcode:
var
  FooClass: TFooClass;
begin
  FooClass := TFooClass.Create;
  try
    Self.Caption := FooClass.FooCaptionEx; // Self ist z.B. TForm1
  finally
    FooClass.Free;
  end;
Folgender Code:
Delphi-Quellcode:
property FooCaption: string read FFooCaption write SetFooCaption;
property FooCaptionEx: string read GetFooCaption;
steht im public Bereich, damit vorhergendes Konstrukt auch dann funktioniert, wenn TFooClass und TForm1 in verschiedenen Units deklariert sind.

......
Lizbeth W.
Ich bin nicht zurück, ich tue nur so
  Mit Zitat antworten Zitat
 


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:03 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz