Wann Get/Set-Methoden und wann Properties?

SideWinder

Gibt es dafür eine Regel? In den Standard-Library findet man leider beides und ich habe bisher noch kein System dahinter entdecken können

MfG SideWinder

Noodles

Properties sind einfach Eigenschaften, wie Name, Alter, Hintergrundfarbe usw.. Intern werde Properties in Get und Set Methoden umgewandelt. Schau Dir mal eine Klasse im ILDASM an.

Artchi

Ich glaub soweit war Sidewinder auch schon. Du hast seine Frage nicht wirklich beantwortet. In der Schule würde man glaubt ich eine 6 bekommen, weil "Thema verfehlt".

Im ernst, ich stelle mir die gleiche Frage wie Sidewinder. Meine einzige Vermutung: bei Properties anstatt get/set spart man sich als Anwender einer Klasse Tiparbeit.

SideWinder

@Noodles: Danke, danke für nichts :p;)

@Artchi: Tiparbeit allein wird doch hoffentlich nicht das ausschlaggebende Argument sein ;). In meinen eigenen Klassen verwende ich jetzt nur noch Properties (Neue Features wollen benutzt werden ;)), hab mir auch schon extra einen Web-Cast zum Thema angesehen. Leider wurde meine Frage dort auch nicht beantwortet.

Ich werde wohl mal in deren Newsgroup posten oder mir den nächsten Web-Cast live ansehen um meine Frage stellen zu können

MfG SideWinder

Noodles

Warum, es steht doch da, bei was Properties verwendet werden. Man braucht also keine Get/Set methoden mehr selbst schreiben.

SideWinder

Es gibt aber in der Standard-Bibliothek auch noch Get/Set-Methoden neben Properties. Nach welcher Regel wird A oder B verwendet?

Du hast mir nur gesagt was Properties *sind*, das weiß ich auch so

MfG SideWinder

Kampino

Vorschlag:
Properties wenn man nur die Eigenschaft ändern will, getter/setter wenn man sonst noch was machen will.
Beispiel:
ein Objekt das einen Kreis darstellt. Die Farbe ist ein Property, sie muss sich nur ändern. Der Umfang wird über getter/setter gemacht, wenn er geämndert wird muss sich auch Flächeninhalt u.ä. ändern

SideWinder

Aber im get/set-Block des Properties kann ich doch auch alles durchführen was ich in einer Get/Set-Methode auch machen kann.

MfG SideWinder

Talla

Wo hast du denn so typische Set/Get Methoden im Sinne von ich weiß einfach nen Wert zu? Immer wenn Eigenschaften einer Klasse wie Felder aussehen sollen benutzt du Properties. Diese 1:1 Umsetzung von privaten Variablen als Properties ist ja aber nur die simpelste Anwendung. Properties verhalten sich ja wie Variablen, und das ist auch ihre Stärke. Selbst wenn keine Variable vorhanden ist, sondern umfangreiche Operationen bei verwenden eines Properties ausgeführt werden, kann man einfach ihnen wie Variablen einfach Werte zuweisen und lesen. Ist meiner Meinung nach übersichtlicher, als mit zig Funktionsaufrufen rumzuhantieren.

SideWinder

War das jetzt auf mein Posting oder auf das von Kampino bezogen?

Ist meiner Meinung nach übersichtlicher, als mit zig Funktionsaufrufen rumzuhantieren.

Dito. Aber wieso verwendet die Standard-Lib dann noch Get/Set-Methoden?

MfG SideWinder

Ein Blick nach Java hilft vielleicht. Dort gibt es so genannte Beans, das sind Komponenten, die den Datenaustausch erleichtern sollen. Es sind Klassen, die
- einen Standardkonstruktor haben
- für jedes Attribut einen öffentlichen Getter und Setter haben

Getter müssen getFoo(), isFoo(), hasFoo(), canFoo() heißen und dürfen keine Parameter haben (stimmt nur fast 100%ig). Setter müssen setFoo() heißen und genau einen Parameter des zum Getter passenden Typs haben. Per Reflection finden dann andere Programme heraus, was dieses Bean so für Attribute hat.

Und jetzt ist klar, warum Properties geil sind. Der XmlSerializer stellt folgende Anforderungen an den Typ:
- er muss einen Standardkonstruktor haben
- er muss für jedes Attribut ein public getter- und setter-Property haben
Das ist das selbe, aber einfacher. Properties sind ein Sprachmittel, um solche Komponenten wie oben aufzubauen. Properties sind die einfachsten Spezialfälle von Gettern und Settern. Ich finde btw. schon, dass man in der Standardbibliothek konsequent Properties verwendet hat, oder hat hier jemand ein gutes Gegenbeispiel?

Talla schrieb:

Properties verhalten sich ja wie Variablen, und das ist auch ihre Stärke.

Das ist leider nicht völlig korrekt. Getter geben einen Wert zurück. Daher ist folgender Code gleich verboten worden, um stundenlanges debuggen zu vermeiden (sei Position ein Property):

meinObjekt.Position.x = 2;

SideWinder

Ich weiß was Beans und Properties sind Aber wieso wird das Konzept nicht durchgehend verwednet. Mir ists jetzt aufgefallen bei GetInsertCommand() von der Klasse OleDbCommandBuilder.

Aber ich habe gerade nachgesehen, die meisten Get/Set-Methoden sind nur vorhanden weil sie überladen wurden. Sind Properties nicht in abgeleiteten Klassen überladbar?

MfG SideWinder

Noodles

Überladbar nicht, aber überschreibbar.

Edit:
Bis auf den Indexer, der ist überladbar.

SideWinder schrieb:

Ich weiß was Beans und Properties sind

Aber weißt du auch, was überladen ist? SCNR

SideWinder

Nicht das was ich eigentlich sagen wollte, aber Noodles hat mich schon richtiggestellt

Also jemand Ahnung warum GetInsertCommand() kein Property ist?

MfG SideWinder

Talla

SideWinder schrieb:

Nicht das was ich eigentlich sagen wollte, aber Noodles hat mich schon richtiggestellt

Also jemand Ahnung warum GetInsertCommand() kein Property ist?

MfG SideWinder

Weils überladen ist?!?

http://msdn2.microsoft.com/en-us/library/system.data.oledb.oledbcommandbuilder.getinsertcommand.aspx

@Optimizer
Ja war wieder schneller geschrieben als zuende gedacht bei mir
Ich nehm einfach mal an das Position bei dir nen struct ist und rein logisch würde ich immer eine neue Position zuweisen und nicht einen Teil der Position ändern. Abgesehen das man mit get ja eh nur lesen kann.

SideWinder

Ach verdammt

Okay, also grundsätzlich immer Properties verwenden nur wenn es sein muss Get/Set-Methoden. Danke soweit

MfG SideWinder