TThread - property oder nicht?

[Pentium 80486]

Hallo,

eher eine simple, fast schon eine überflüssige Frage, welche mir dennoch wichtig erscheint.

Sollte man beim Erstellen eines Threads lieber mit properties oder mit "einfachen Variablen" arbeiten?

Beispiel mit Properties:

Delphi-Quellcode:

type
 TMyThread = class(TThread)
 private
  { Private-Deklarationen }
  FsTest: String;
 public
  { Public-Deklarationen }
  property sTest: String read FsTest write FsTest;
 end;

// . . .

aMyThread := TMyThread.Create;
aMyThread.sTest := 'Test';

Beispiel mit Variablen:

Delphi-Quellcode:

type
 TMyThread = class(TThread)
 private
  { Private-Deklarationen }
 public
  { Public-Deklarationen }
  sTest: String;
 end;

// . . .

aMyThread := TMyThread.Create;
aMyThread.sTest := 'Test';

[himitsu]

Welche Delphi-Version hattest du nochmal?


Gib einfach mal das ein

Delphi-Quellcode:

type
  TMyThread = class(TThread)
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
    property sTest: String;
  end;

und das Strg+Shift+C (Klassenvervollständigung) drücken, mit Textcursor innerhalb der Klassendeklaration.
Wenn das geht, dann auf jeden Fall Property ... ist nicht mehr Arbeit und in Zukunft läßt sich der Zugriff naträglich noch ganz bequem regeln. (z.B. Getter und Setter einbauen)

[Pentium 80486]

Klappt wunderbar mit delphi XE2.

Bleibt nur die Frage, ob man dann aMyThread.SetsTest('Test'); oder aMyThread.sTest := 'Test'; nehmen sollte.

Im Prinzip ist es doch dasselbe. Nur eine Style-Guide-Frage (denke ich).

[himitsu]

Delphi dürfte doch SetsTest im Private erstellt haben?

Dann beantwortet sich die Frage von selber.



Ich halte es so:
- Extern immer über den Property
- Intern direkt auf das Feld oder auf den Setter, jenachdem was benötigt wird ... so sieht man dann auch ganz schnell was verwendet wird. (ohne das F zu übersehn)

[sx2008]

Also ich verwende zu Beginn der Entwicklung meistens einfache Variablen; ganz einfach deswegen, weil man weniger Schreibaufwand benötigt und schneller ändern kann. (Zumindest dann wenn die IDE keine Unterstützung zum Refaktorieren bietet)

Später, wenn sich die Klasse und die öffentlich sichtbaren Methoden & Variablen stabilisiert haben, mache ich aus den einfachen Variablen richtige Properties.

[Pentium 80486]

Ich hätte nicht gedacht, dass ich die Umstellung von "alt" auf "neu" (mit Properties) so schnell vollziehen kann!

Wo vorher z.B. sMeinString:String; stand, einfach ein property sMeinString:String; draus gemacht, STRG+Shift+C gedrückt, fertig.

Jetzt kenne ich leider den technischen Unterschied von meinem "alten" und dem "neuen" Code nicht. Gibt es da überhaupt einen?
Denn es muss ja einen Grund geben, warum properties vorgezogen werden.

[sahimba]

Zitat von Pentium 80486:

Denn es muss ja einen Grund geben, warum properties vorgezogen werden.

Wie "himitsu" schon schrieb

Zitat:

und in Zukunft läßt sich der Zugriff naträglich noch ganz bequem regeln

kannst Du so später, ohne Deinen bestehenden Code großartig zu ändern, Kontrollen vornehmen.

Bspw. stellst Du später fest, dass sich der Wert einer Property nur innerhalb eines bestimmten Bereiches bewegen darf/soll, der übergebene String nicht leer sein soll, etc.pp. so brauchst Du das bestehende write FPropertyName nur in ein write SetPropertyName zu ändern und kannst dies dort, in dem dann hinzugefügtem Setter, implementieren statt, was zu fehlerträchtigen Codeduplizierungen führen würde, diese Einschränkung(en) beim Aufrufer sicherzustellen.

[Blup]

Insbesondere Thread-Klassen sind ein gutes Beispiel warum Properties benötigt werden.
Soll auf Variablen vom Hauptthreat und vom Thread der Klasse selbst zugegriffen werden,
ist z.B. eine TCriticalSection notwendig, damit es nicht zu Konflikten kommt.

Delphi-Quellcode:

type
  TMyThread = class(TThread)
    constructor Create;
    destructor Destroy; override;
  private
    FCS: TCriticalSection;
    FValue1: Integer;
    FValue2: string;
    function GetValue1: Integer;
    function GetValue2: string;
    procedure SetValue1(AValue: Integer);
    procedure SetValue2(AValue: string);
  public
    property CS: TCriticalSection read FCS;
    property Value1: Integer read GetValue1 write SetValue1; 
    property Value2: string read GetValue2 write SetValue2;
    procedure ReadFromStream(AStream: TStream);
    procedure WriteToStream(AStream: TStream); 
  end;

constructor TMyThread.Create;
begin
  inherited;
  FCS := TCriticalSection.Create;
end;

destructor TMyThread.Destroy;
begin
  FCS.Free;
  inherited;
end;

function TMyThread.GetValue1: Integer;
begin
  CS.Enter;
  try
    Result := FValue1;
  finally
    CS.Leave;
  end;
end;

function TMyThread.GetValue2: string;
begin
  CS.Enter;
  try
    Result := FValue2;
  finally
    CS.Leave;
  end;
end;

procedure TMyThread.SetValue1(AValue: Integer);
begin
  CS.Enter;
  try
    FValue1 := AValue;
  finally
    CS.Leave;
  end;
end;

procedure TMyThread.SetValue2(AValue: string);
begin
  CS.Enter;
  try
    FValue2 := AValue;
  finally
    CS.Leave;
  end;
end;

procedure TMyThread.ReadFromStream(AStream: TStream);
begin
  {Zugriffe anderer Threads sperren}
  CS.Enter;
  try
    {Value1 lesen} 
    {Value2 lesen} 
  finally
    CS.Leave;
  end;
  {Zugriffe von anderen Threads wieder frei}
end;

procedure TMyThread.WriteToStream(AStream: TStream); 
begin
  {Zugriffe anderer Threads sperren}
  CS.Enter;
  try
    {Value1 speichern} 
    {Value2 speichern} 
  finally
    CS.Leave;
  end;
  {Zugriffe von anderen Threads wieder frei}
end;