Frage zu Propertys

[DeddyH]

Welchen Unterschied macht es für den Benutzer einer Klasse, ob eine Property so deklariert ist
property SomeProp: integer read FSomeProp write FSomeProp; oder so
property SomeProp: integer read GetSomeProp write SetSomeProp; ?

[Sir Rufo]

Zitat von DeddyH:

Welchen Unterschied macht es für den Benutzer einer Klasse, ob eine Property so deklariert ist
property SomeProp: integer read FSomeProp write FSomeProp; oder so
property SomeProp: integer read GetSomeProp write SetSomeProp; ?

Bis auf die Geschwindigkeit, keinen

[alda]

Zitat:

Würde ich nicht so sehen. Denn eine Property abstrahiert den Zugriff auf die eigentliche private Variable.

Das ist korrekt. Dennoch ist es nichts anderes als das direkte (über read/write) veröffentlichen dieser Variable, was ich persönlich , wie erwähnt, unsauber finde.

Zitat:

Wenn sich der interne Typ ändert, kannst Du dann auch das read/write auf einen Getter/Setter setzen. Warum sollte man gezwungen werden Methoden zu implementieren, welche nichts machen?

Nun, die Methoden machen etwas: Sie Setzen (Set..) und Lesen (Get..) Informationen einer Klasse Oder worauf willst Du hinaus? Ich finde man sollte immer schauen, was im Rahmen des vertretbaren liegt um sauberen und wiederverwendbaren Code zu produzieren. Getter und Setter zu verwenden ist in meinen Augen ein Standard, auch wenn Delphi Dir die Möglichkeit bietet direkt die Variablen hinter der Property zu verstecken (wie gesagt, auch ich mach das in seltenen Fällen so).

[mkinzler]

Zitat von alda:

Zitat:

Würde ich nicht so sehen. Denn eine Property abstrahiert den Zugriff auf die eigentliche private Variable.

Das ist korrekt. Dennoch ist es nichts anderes als das direkte (über read/write) veröffentlichen dieser Variable, was ich persönlich , wie erwähnt, unsauber finde.

Nein ist es nicht:
-Der Konsument der Klasse sieht nicht, ob es sich um einen direkten Zugriff auf die Variable handelt oder ein Getter/Setter involviert ist.
-Der Typ der Internen Varibel kann unabhängig vom Typ der Property geändert werden ( u.U. muss man dann Getter/Setter implemnetieren)
-Man kann nachträglich Getter/Setter einführen ohne das der Konsument etwas davon merkt-

Zitat:

Zitat:

Wenn sich der interne Typ ändert, kannst Du dann auch das read/write auf einen Getter/Setter setzen. Warum sollte man gezwungen werden Methoden zu implementieren, welche nichts machen?

Nun, die Methoden machen etwas: Sie Setzen (Set..) und Lesen (Get..) Informationen einer Klasse Oder worauf willst Du hinaus? Ich finde man sollte immer schauen, was im Rahmen des vertretbaren liegt um sauberen und wiederverwendbaren Code zu produzieren. Getter und Setter zu verwenden ist in meinen Augen ein Standard, auch wenn Delphi Dir die Möglichkeit bietet direkt die Variablen hinter der Property zu verstecken (wie gesagt, auch ich mach das in seltenen Fällen so).

Wenn es nichts zu überprüfen gibt, warum sollte man dann die Implementierung einer Methode erzwingen? (Man erhöht dadurch nur den Aufwand/Verringert die Performance).
Zwingend Setter/getter zu verwenden und nur bei Java so, weil es dort keine Properties gibt! In C# wurde im Großen-und-Ganzen das Verhalten von Delphi übernommen ( sogar vereinfacht, da inline)

[alda]

Zitat:

Wenn es nichts zu überprüfen gibt, warum sollte man dann die Implementierung einer Methode erzwingen? (Man erhöht dadurch nur den Aufwand/Verringert die Performance).
Zwingend Setter/getter zu verwenden und nur bei Java so, weil es dort keine Properties gibt! In C# wurde im Großen-und-Ganzen das Verhalten von Delphi übernommen ( sogar vereinfacht, da inline)

Gute Frage, das gehört für mich einfach mit zum objektorientierten Design (genau wie die Verwendung von Interfaces an dieser Stelle, die den Zugriff (z.b. dieser Property) nach außen reglementieren). Da haben ich wohl einfach eine andere Vorgehensweise

Nach der Argumentation könnte man doch theoretisch auch fragen wofür man überhaupt Klassen und Klassenmethoden verwendet, anstatt diese "einfach" prozedural ohne Klasse runterzutippen und globale Variablen zu verwenden. Das geht mit Sicherheit auch schneller (geringerer Aufwand) und ist vielleicht beim Zugriff auch schneller ohne die Klassenzuordnung (wobei ich mir bei den Methodenaufrufen performancetechnisch keine Gedanken mache, außer vielleicht ich entwickle für eine wirklich schwache Platform (TV embedded oder ähnliches)).

Und was C# angeht: Soweit ich mich erinnere kann ich da auch nicht direkt auf eine Variable verweisen, sondern habe lediglich die Möglichkeit, Getter und Setter in "verkürzter" Form zu implementieren - muss aber trotzdem einen Wert rausgeben (Result := FBla) und einen Wert verarbeiten (FBla := AValue), was dann wiederum einer Kapselung in eine Methode entspricht.

[Mikkey]

Zitat von alda:

Und was C# angeht:

Nur damit Ihr von demselben sprecht:

In C# sieht das so aus:

Code:

private int var;  // Variablendefinition

public int Var            // Property-Definition
{
  get{ return var; }   // Getter
  set{ var = value; }  // Setter
}

[Dejan Vu]

Zitat von Sir Rufo:

Zitat von DeddyH:

Welchen Unterschied macht es für den Benutzer einer Klasse, ob eine Property so deklariert ist
property SomeProp: integer read FSomeProp write FSomeProp; oder so
property SomeProp: integer read GetSomeProp write SetSomeProp; ?

Bis auf die Geschwindigkeit, keinen

Doch. Der Leser der Klasse muss ständig zur Implementierung scrollen, nur um zu sehen, das sie nichts macht, außer das Feld zu liefern/zu beschreiben. Vollkommen überflüssig also. Eine Implementierung sollte auch etwas implementieren und man sollte i.a. die kürzeste Variante nehmen, die für die Implementierung einer Aufgabe zur Verfügung steht (vorbehaltlich der Lesbarkeit). Wenn die Intention des Setters/Getters eine zusätzliche Funktionalität ist, dann kann man so einen quasi leeren Getter/Setter durchaus anlegen. Es soll ja noch etwas hinzukommen (Kommentare durchaus erwünscht). Aber nur, um Code zu produzieren... Also ich weiß nicht.

Zitat von alda:

...das gehört für mich einfach mit zum objektorientierten Design

Das *produzieren* von überflüssigem Code????

Zitat:

Nach der Argumentation könnte man doch theoretisch auch fragen

Kann man. Aber wenn man seinen Kopf einschaltet, fragt man das nicht

Zitat:

Und was C# angeht: Soweit ich mich erinnere kann ich da auch nicht direkt auf eine Variable verweisen, sondern habe lediglich die Möglichkeit, Getter und Setter in "verkürzter" Form zu implementieren - muss aber trotzdem einen Wert rausgeben (Result := FBla) und einen Wert verarbeiten (FBla := AValue), was dann wiederum einer Kapselung in eine Methode entspricht.

Nope.

Code:

public int Var {get;set;}

Nennt sich Autoproperty und ist einfach die Konsequenz aus dem, was Du ablehnst.

[alda]

Zitat:

public int Var {get;set;}

Merci, das kannte ich nicht.

Zitat:

Das *produzieren* von überflüssigem Code????

Wie gesagt, wer definiert was überflüssig ist. Da ich ausschließlich über Interfaces arbeite, habe ich auch immer (wie Ihr Sie nennt, "leere") Getter und Setter und keine Variablennamen in den Properties. Sollte ich in irgendeinem Fall was ohne Interfaces hinklatschen, verwende ich es in seltenen Fällen auch über die Angabe einer Variablen. Hätte auch nicht gedacht (oder nie darüber nachgedacht), dass man das als "überflüssigen" Code ansieht, aber man lernt ja nie aus

Zitat:

Kann man. Aber wenn man seinen Kopf einschaltet, fragt man das nicht

Das liegt wohl im Auge des Betrachters und seiner Arbeitsweise/Kenntnisstandes. Wenn ich lese, dass es in Delphi elegant sein soll eine Variable direkt über eine Property zu veröffentlichen, dann frag ich mich auch ob derjenige seinen Kopf eingeschaltet hat, würde das aber nicht so kommunizieren, weil es a) einfach nicht konstruktiv ist und es b) immer Ausnahmen gibt.

Wenn ich eine Property property SomeProp: integer read FSomeProp write FSomeProp; verwende, dann verwende ich kein Interface für den Zugriff darauf. Wenn ich kein Interface verwende, habe ich keinen definierten Zugriff auf eine Klasse und kann diese in Delphi entsprechend nicht so einfach für den Test mocken. (außer ich mache es Quick and Dirty und erstelle mir im Testprojekt eine Kopie der Unit und implementiere dort meinen Stubcode). Und das ist eben der Grund warum ich den "überflüssigen" Code bevorzuge.

[mkinzler]

Zitat:

Wie gesagt, wer definiert was überflüssig ist. Da ich ausschließlich über Interfaces arbeite, habe ich auch immer (wie Ihr Sie nennt, "leere") Getter und Setter und keine Variablennamen in den Properties.

Delphi-Quellcode:

type
TPerson = class
 private
  FVorname, FNachname: string;
 published
  property Vorname: string read FVorname write FVorname;
end;

TPerson2 = class
 private
  FVorname, FNachname: string;
 public
  proedure setVorname( AValue: string);
 published
  property Vorname: string read FVorname write setVorname;
end;
...
var
  p1: TPerson;
  p2: TPerson2;
...

//Kein Unterschied bei der Verwendung, nur mehr Code
  p1.Vorname := 'Franz';
  p2.Vorname := 'Otto';

Aber der wahre Unterschied sieht man im Erzeugten Laufzeitcode
p1.Vorname := 'Franz'; wird zu p1.FVorname := 'Franz'; p2.Vorname := 'Otto'; wird zu p2.setVorname( 'Otto'); -> p2.FVorname := 'Otto'; Im Endeffekt wird das selber gemacht nur hat man anstatt einer normalen Wertzuweisung noch einen Methodenaufruf dazwischen.

Und dieser ist imho überflüssig.

Interfaces sind sinnvoll aber nicht immer und für Alles.

[Dejan Vu]

Zitat von alda:

Da ich ausschließlich über Interfaces arbeite....Und das ist eben der Grund warum ich den "überflüssigen" Code bevorzuge.

Jo. Bei Delphi ist das dann so. Blöd, aber isso. Hauptsache testbar und -so wie Du das machst- klare Zugriffe über Interfaces.