Frage zu Propertys

[ByTheTime]

Hallo,
wenn ich eine Klasse schreibe und eine Property lesen und schreiben möchte, dann schreibe ich mir für das Schreiben immer einen "Setter", wie es hier beschrieben ist. Das habe ich schon immer so gemacht.

Aber was spricht denn gegen

Delphi-Quellcode:

property Name: String read FName write FName;

?
Ich schreibe ja auch nicht für jede Property einen "Getter"...

Gruß,
Lukas

[Dejan Vu]

Eigentlich gar nichts.

[ByTheTime]

Hmmm... Dann werde ich das in Zukunft so machen :thumb:

[Lemmy]

ist mehr zu schreiben als

Delphi-Quellcode:

property Name: String;

und anschließend Shift+SRTG+C

[Dejan Vu]

Und mehr überflüssiger Code.

[Sir Rufo]

Zitat:

Zitat von Lemmy (Beitrag 1261099)

ist mehr zu schreiben als

Delphi-Quellcode:

property Name: String;

und anschließend Shift+SRTG+C

stimmt

Delphi-Quellcode:

propf

und TAB und den Namen :mrgreen:

[Dejan Vu]

Wo war jetzt nochmal im Eingangspost die Bemerkung, das die Anzahl der Tastendrücke irgendeine Rolle spielt? :gruebel:

[himitsu]

Wenn im Setter absolut nichts gemacht wird, außer in das Feld zu schreiben, dann ist der natürlich sinnlos und du kannst direkt in das Feld schreiben.
Vom Code her ist es dennoch möglich später einen Setter einzufügen, wenn dieser nun doch benötigt wird.

Der Vorteil beim Setter ist, daß du dort einen Haltepunkt reinmachen kannst, um Schreibzugriffe zu debuggen.
Oder man kann dort den zugewiesenen Wert prüfen und ungültige Werte unterbinden.
Aber, wie bereits erwähnt, dannst du den nötigen Setter dann immernoch einbauen.

Zitat:

Zitat von Sir Rufo (Beitrag 1261109)

stimmt

Delphi-Quellcode:

propf

und TAB und den Namen :mrgreen:

propf[space]Bar[enter]string[enter]

http://www.delphipraxis.net/179343-k...ml#post1250033
http://www.delphipraxis.net/180540-e...ml#post1260501
...

PS: Diese Vorlagen erzeugen sogar das Feld

Delphi-Quellcode:

FName: string;

, wenn es noch nicht existiert.



[add]
http://www.delphi-treff.de/object-pa...n-und-objekte/

Das Tutorial sollte man besser mal reparieren. :wall:

Zitat:

Delphi-Quellcode:

Destructor Free;

Free?
Und wo ist das Override?
Und wo sind die Inherited?
Und weiter wollte ich nicht mehr schauen, da ich Angst bekommen hab.

[alda]

Wenn ich noch etwas hinzufügen darf:
Properties mit direkten Lese- und/oder Schreibzugriff auf Variablen sind meines Erachtens unsauber und "starr" (natürlich gibt es wirklich Ausnahmen, bei denen es sich für uns Delphi-Entwickler vielleicht wirklich nicht lohnt extra Getter/Setter anzulegen). Aber letztendlich entspricht das der Veröffentlichung einer Variable (also "public FVariable: Integer" (Lesen + Schreiben)) und ist auch in anderen Sprachen eher ein NoGo würde ich sagen.

Es macht meines Erachtens in den meisten Fällen durchaus Sinn sich die "Mühe" zu machen Getter und Setter zu schreiben, da man so viel flexibler ist. Außerhalb deiner Klasse hat es niemanden zu interessieren was Du intern machst (z.B. den Wert in die entsprechende Variable zu schreiben). Mit Flexibel meine ich: Du musst deine Property-Deklaration nicht anpassen wenn Du die interne Variable änderst (read/write Sektion) und Du kannst problemlos weitere Aktionen innerhalb der Getter und Setter antriggern, die im Laufe der Entwicklung vielleicht noch kommen (nach dem Setzen z.B. Log schreiben, vor dem Lesen ein Flag setzen oder sonst was).

Ich finde es am elegantesten gleich mit Interfaces zu arbeiten, wo Du dann auch gezwungen wärst (;-))Getter und Setter zu implementieren. Hier hast Du dann in den Tests auch den Vorteil, deine Klassen einfacher zu mocken (durch Testklassen auszutauschen).

[mkinzler]

Zitat:

Properties mit direkten Lese- und/oder Schreibzugriff auf Variablen sind meines Erachtens unsauber und "starr" (natürlich gibt es wirklich Ausnahmen, bei denen es sich für uns Delphi-Entwickler vielleicht wirklich nicht lohnt extra Getter/Setter anzulegen). Aber letztendlich entspricht das der Veröffentlichung einer Variable (also "public FVariable: Integer" (Lesen + Schreiben)) und ist auch in anderen Sprachen eher ein NoGo würde ich sagen.

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

Zitat:

Es macht meines Erachtens in den meisten Fällen durchaus Sinn sich die "Mühe" zu machen Getter und Setter zu schreiben, da man so viel flexibler ist. Außerhalb deiner Klasse hat es niemanden zu interessieren was Du intern machst (z.B. den Wert in die entsprechende Variable zu schreiben).

Wie gesagt eine Property abstrahiert.

Zitat:

Mit Flexibel meine ich: Du musst deine Property-Deklaration nicht anpassen wenn Du die interne Variable änderst (read/write Sektion) und Du kannst problemlos weitere Aktionen innerhalb der Getter und Setter antriggern, die im Laufe der Entwicklung vielleicht noch kommen (nach dem Setzen z.B. Log schreiben, vor dem Lesen ein Flag setzen oder sonst was).

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?

[DeddyH]

Welchen Unterschied macht es für den Benutzer einer Klasse, ob eine Property so deklariert ist

Delphi-Quellcode:

property SomeProp: integer read FSomeProp write FSomeProp;

oder so

Delphi-Quellcode:

property SomeProp: integer read GetSomeProp write SetSomeProp;

?

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1261188)

Welchen Unterschied macht es für den Benutzer einer Klasse, ob eine Property so deklariert ist

Delphi-Quellcode:

property SomeProp: integer read FSomeProp write FSomeProp;

oder so

Delphi-Quellcode:

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:

Zitat von alda (Beitrag 1261193)

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 :P

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:

Zitat von alda (Beitrag 1261196)

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:

Zitat von Sir Rufo (Beitrag 1261191)

Zitat:

Zitat von DeddyH (Beitrag 1261188)

Welchen Unterschied macht es für den Benutzer einer Klasse, ob eine Property so deklariert ist

Delphi-Quellcode:

property SomeProp: integer read FSomeProp write FSomeProp;

oder so

Delphi-Quellcode:

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:

Zitat von alda (Beitrag 1261196)

...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

Delphi-Quellcode:

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

Delphi-Quellcode:

p1.Vorname := 'Franz';

wird zu

Delphi-Quellcode:

p1.FVorname := 'Franz';

Delphi-Quellcode:

p2.Vorname := 'Otto';

wird zu

Delphi-Quellcode:

p2.setVorname( 'Otto');

->

Delphi-Quellcode:

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:

Zitat von alda (Beitrag 1261220)

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.

[alda]

Zitat:

Und dieser ist imho überflüssig. Interfaces sind sinnvoll aber nicht immer und für Alles.

Klar, Ausnahmen bestätigen die Regel. Worauf ich hinaus will ist, dass man eben nicht sagen kann, dass es pauschal "überflüssig" ist, sofern man den Verwendungszweck nicht kennt.

Die Frage die der TE stellte, war:
"Aber was spricht denn gegen property Name: String read FName write FName; ?"

Und mein geschilderter Anwendungsfall wäre somit ein Punkt, der m.E. dagegen spricht :>

[Popov]

@alda

Ich will jetzt nicht mit dem Spruch kommen, dass alles was Delphi-Entwickler vormachen gleich richtig ist, aber guckt man sich die Delphi-Units an, wird nirgendwo über Setter oder Getter auf eine Feldvariable zugegriffen. Die Regel ist

Delphi-Quellcode:

property SomeProp: integer read FSomeProp write FSomeProp;

. Nur wenn noch etwas Code dazukommt wird es anders gemacht.

Der Entwickler macht es also vor, warum soll man es anders machen?

[ByTheTime]

So stell ich mir eine lebhafte Diskussion vor :) :thumb:

[Jumpy]

Zitat:

Zitat von Dejan Vu (Beitrag 1261234)

Zitat:

Zitat von alda (Beitrag 1261220)

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.

Hallo und guten Morgen,

kann mir jemand mal erklären wie das gemeint ist mit den Interfaces und der Testbarkeit?

Eine Klasse mit einer Property, die direkt auf die Feldvariable schreibt/liest, kann man nicht testen? Und es geht doch um eine Klasse, wie kommen da jetzt Interfaces ins Spiel?

[mkinzler]

Er meint keine Properties und dafür nur Getter/Setter, die er durch Interfaces definiert. ( Die Implementierung/Attribute ist/sind dann black box)

[OlafSt]

Ist es nicht letztlich eine Frage des Anwendungsfalles - wie so oft ?

Ich persönlich benutze absolut überhaupt keine Interfaces, weil es schlicht keine Notwendigkeit bisher dazu gab (Faulheit in Sachen Speicher nicht mehr freigeben ist keine für mich :lol:). Ergo sind für mich Getter/Setter, die nichts weiter tun, als Werte einzuschreiben bzw. wieder auszulesen absolut überflüssiger Code, der nur Platz und Laufzeit kostet. Folglich habe ich faktisch nur "propf"'s im Code.

Ganz anders unser Interface-Mensch, der alles und jeden in ein Interface steckt - der ist gezwungen, Getter/Setter zu haben, selbst wenn sie nur einschreiben bzw. auslesen (was für mich bereits ein Grund ist, Interfaces möglichst zu meiden - unnötigen Code produzieren zu müssen).

So hat jeder sein Kreuz zu tragen ;)

[Dejan Vu]

Zitat:

Zitat von OlafSt (Beitrag 1261335)

was für mich bereits ein Grund ist, Interfaces möglichst zu meiden - unnötigen Code produzieren zu müssen).

Interfaces sind jetzt nicht dazu gedacht, einem das Programmiererleben noch etwas schwerer zu machen, sondern eher dafür, um mit anderen Programmen kommunizieren zu können und die Sichtbarkeit für die Außenwelt zu regeln. In der DLL willst/musst Du vielleicht auf public member der Klasse zugreifen, aber außerhalb der DLL nicht. Und da übergibst Du das Objekt eben als interfaced object und schon ist alles geschützt.

Interfaces nur um der Interfaces willen ist genauso intelligent wie Setter nur um der Setter willen.

[himitsu]

Zitat:

Zitat von Jumpy (Beitrag 1261305)

kann mir jemand mal erklären wie das gemeint ist mit den Interfaces und der Testbarkeit?

Man nutzt z.B. im Programm nur das Interface und kann zum Testen die Klasse/Objektinstanz hinter dem Interface austauschen.

Zum Testen wird einfach eine andere Klasse verwendet, welche zusätzliche Debugfeatures enthält oder die immer nur definierte Testdaten liefert, so daß man immer wieder das gleiche Verhalten hat, welches sich leichter testen lässt, da man dann immer das selbe Ergebnis rausbekommt.


z.B. du hast einen Parser/Auswertecode, welcher getestet werden soll, dann wird in diesem Fall die Klasse ausgetauscht, welche die zu verarbeitenden Daten liefert.
Man kann auch die Anzeigeklasse austauschen, welche die verarbeiteten Daten gleich prüft.

Grund: Man testet nur den einen Zwischenteil, da drumrum alles gegen funktionierend Testklassen ausgetauscht wurde.

So lässt sich jeder Teil einzeln prüfen und man weiß genau wo der Fehler ist.
Schaust du zum Test aber nur auf die Anzeige, dann kann der Fehler sonstwo sein.

[alda]

Zitat:

@alda
Ich will jetzt nicht mit dem Spruch kommen, dass alles was Delphi-Entwickler vormachen gleich richtig ist, aber guckt man sich die Delphi-Units an, wird nirgendwo über Setter oder Getter auf eine Feldvariable zugegriffen. Die Regel ist property SomeProp: integer read FSomeProp write FSomeProp; . Nur wenn noch etwas Code dazukommt wird es anders gemacht.

Der Entwickler macht es also vor, warum soll man es anders machen?

Wie gesagt, man kann nicht pauschal sagen, dass es gut oder schlecht ist. Das bestätigst Du ja mit Deiner Aussage :P Genau so kannst Du nicht sagen, dass es gut ist weil die Delphi-Entwickler es so machen, das ist doch kein Argument. Es geht doch darum wann etwas sinnvoll ist und wann nicht und nicht *wer* es implementiert hat. Nur weil die z.B. (achtung, Behauptung! :P) Delphi-Entwickler nicht Test-Driven entwickeln, heißt das nicht dass das sinnvoll ist und ich es auch nicht mache.

Zitat:

Hallo und guten Morgen,
kann mir jemand mal erklären wie das gemeint ist mit den Interfaces und der Testbarkeit?
Eine Klasse mit einer Property, die direkt auf die Feldvariable schreibt/liest, kann man nicht testen? Und es geht doch um eine Klasse, wie kommen da jetzt Interfaces ins Spiel?

Testen kannst Du es schon, aber NUR diese Klasse, da Du jeden der mit der Klasse arbeitet an die Klasse bindest. Wenn Du von außerhalb mit einem Interface arbeitest, welches von Deiner Klasse implementiert wird, dann kennst Du die Klasse hinter dem Interface nicht und hast somit in komplexeren Tests kein Problem die Klasse hinter dem Interface auszutauschen, da Du überall nur mit dem definierten Interface darauf zugreifst und nicht direkt über die Klasse.

Zitat:

Ist es nicht letztlich eine Frage des Anwendungsfalles - wie so oft ?

Ich persönlich benutze absolut überhaupt keine Interfaces, weil es schlicht keine Notwendigkeit bisher dazu gab (Faulheit in Sachen Speicher nicht mehr freigeben ist keine für mich ). Ergo sind für mich Getter/Setter, die nichts weiter tun, als Werte einzuschreiben bzw. wieder auszulesen absolut überflüssiger Code, der nur Platz und Laufzeit kostet. Folglich habe ich faktisch nur "propf"'s im Code.

Ganz anders unser Interface-Mensch, der alles und jeden in ein Interface steckt - der ist gezwungen, Getter/Setter zu haben, selbst wenn sie nur einschreiben bzw. auslesen (was für mich bereits ein Grund ist, Interfaces möglichst zu meiden - unnötigen Code produzieren zu müssen).

So hat jeder sein Kreuz zu tragen

Da würde mich mal interessieren wie komplexere Tests bei Dir aussehen, wenn Du garkeine Interfaces verwendest? Ich hab diesen Fall z.B. sehr oft.

Zitat:

So stell ich mir eine lebhafte Diskussion vor

Find ich super, da ich ansonsten keine Möglichkeit habe mir Delphi-spezifische Meinungen einzuholen :P

[Jumpy]

Zitat:

Zitat von alda (Beitrag 1261340)

Zitat:

Hallo und guten Morgen,
kann mir jemand mal erklären wie das gemeint ist mit den Interfaces und der Testbarkeit?
Eine Klasse mit einer Property, die direkt auf die Feldvariable schreibt/liest, kann man nicht testen? Und es geht doch um eine Klasse, wie kommen da jetzt Interfaces ins Spiel?

Testen kannst Du es schon, aber NUR diese Klasse, da Du jeden der mit der Klasse arbeitet an die Klasse bindest. Wenn Du von außerhalb mit einem Interface arbeitest, welches von Deiner Klasse implementiert wird, dann kennst Du die Klasse hinter dem Interface nicht und hast somit in komplexeren Tests kein Problem die Klasse hinter dem Interface auszutauschen, da Du überall nur mit dem definierten Interface darauf zugreifst und nicht direkt über die Klasse.

Bei uns wird nicht mit Unit-Tests (das ist ja hier im Zusammenhang mit Test gemeint, denk ich) gearbeitet. Nicht weil wir keine Fehler machen, sondern weil... (kann da jetzt kein Agument angeben, dass nicht irgendwer wieder entkräften könnte, aber es läuft auf "Zu Aufwendig für unsere kleinen Projekte" und "So ne neumodische Krams hammer he noch nie jemacht" hinaus).

Deswegen kenn ich mich da nicht aus und frag vllt. dumm. Aber wenn ich statt mit Interfaces mit abstrakten Vorfahren-Klassen arbeite könnte ich doch dagegen testen? Und im Gegensatz zu Interfaces kann es in abstrakten Klassen ja Felder geben und dementsprechend direkt durchgreifende Properties
Und wenn ein Nachfahre mal nicht direkt durchgreift, sondern getter und setter hat, merk ich das von aussen noch nicht mal.

Aber wie gesagt, kenne Unit-Testing nicht und vermute mal, dass diese Frameworks dafür mit Interfaces arbeiten?

[Sir Rufo]

Mit einem/mehreren Interfaces kannst du dir eine große Testklasse bauen um dann den Teil zu testen, der diese Interfaces benutzt.

z.B. protokolliert die Testklasse jeden Interface-Aufruf.

Delphi-Quellcode:

TMockTest = class( TInterfacedObject, IFoo, IBar, IWeiss, IGelb )
...
end;

Bei einer/mehreren abstrakten Klasse/n geht das eben nicht.

[alda]

Zitat:

Bei uns wird nicht mit Unit-Tests (das ist ja hier im Zusammenhang mit Test gemeint, denk ich) gearbeitet. Nicht weil wir keine Fehler machen, sondern weil... (kann da jetzt kein Agument angeben, dass nicht irgendwer wieder entkräften könnte, aber es läuft auf "Zu Aufwendig für unsere kleinen Projekte" und "So ne neumodische Krams hammer he noch nie jemacht" hinaus).

Deswegen kenn ich mich da nicht aus und frag vllt. dumm. Aber wenn ich statt mit Interfaces mit abstrakten Vorfahren-Klassen arbeite könnte ich doch dagegen testen? Und im Gegensatz zu Interfaces kann es in abstrakten Klassen ja Felder geben und dementsprechend direkt durchgreifende Properties
Und wenn ein Nachfahre mal nicht direkt durchgreift, sondern getter und setter hat, merk ich das von aussen noch nicht mal.

Aber wie gesagt, kenne Unit-Testing nicht und vermute mal, dass diese Frameworks dafür mit Interfaces arbeiten?

Das mit dem zu "Aufwendig und neumodisch" war bei uns auch anfangs so. Was dieses Thema angeht kann ich Dir/Euch nur Uncle Bob ans Herz legen: http://cleancoders.com/
Denn Test-Driven Development ist alles andere, als aufwendig ;>

Naja also erst einmal kannst Du das nur, wenn alles was zu testen ist (also alles :P) auch vom Basis-Vorfahren implementiert wird. Das bedeutet wiederum, dass Du immer mit dem Typ der Basisklasse arbeiten musst (meineVariable: TBasisklasse) und damit koppelst Du die Verwendung wieder an eine Klasse (dann eben TBasisklasse). Hierfür müsstest Du dann deine Stubklassen für den Test vom Basis-Vorfahren ableiten und musst diese auch immer anpassen, sofern sich etwas (vielleicht irrelevantes für deinen Test) an der Basis-Klasse ändert.
Genau für diesen Fall sind eben nunmal Interfaces gedacht, auch wenn es Sprachen gibt, die dieses abstrakte Modell verfolgen (z.B. Python). Vererbung beschreibt nunmal eine gemeinsame Vorgehensweise und ein Interface eben eine gemeinsame Schnittstelle. Und für den Test unterscheidet sich die Vorgehensweise (die Implementierung) nunmal von der, der Basisklasse