Frage zu Propertys

[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?