Wann Get/Set-Methoden und wann Properties?
-
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
-
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
-
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
-
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.
-
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 habenGetter 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;
-
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
-
Ü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
-
Nicht das was ich eigentlich sagen wollte, aber Noodles hat mich schon richtiggestellt
Also jemand Ahnung warum GetInsertCommand() kein Property ist?
MfG SideWinder
-
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.
-
Ach verdammt
Okay, also grundsätzlich immer Properties verwenden nur wenn es sein muss Get/Set-Methoden. Danke soweit
MfG SideWinder