Einbindung Property (Beispiel Dictionary?)

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 11 Antworten in diesem Thema. Der letzte Beitrag () ist von Yanbel.

    Einbindung Property (Beispiel Dictionary?)

    Hallo,

    Properties haben ja Get und Set Funktionen. Bisher habe ich für Properties nur langweilige Dinge wie Integers, da nutze ich diese Methoden quasi nie anders als sie standardmäßig sind.

    Jetzt habe ich ein Dictionary als Property erstellt und dachte das wäre eventuell eine Klasse, die einen Nutzen aus costum Property Funktionen zieht.
    Ich kann wie gewohnt das Dictionary ersetzen oder ich ersetze nur die Elemente.
    Ist das sinnvoll oder eher Blödsinn, da die Element ja an sich schon in einem Dictionary existieren?
    Wann nutzt ihr nicht-standard Properties?

    VB.NET-Quellcode

    1. Friend Property LetzteAuswertung As Dictionary(Of String, DateTime)
    2. Get
    3. Return _LetzteAuswertung
    4. End Get
    5. Set
    6. _LetzteAuswertung = Value
    7. End Set
    8. End Property
    9. '------------------
    10. Friend Property LetzteAuswertung As Dictionary(Of String, DateTime)
    11. Get
    12. Return _LetzteAuswertung
    13. End Get
    14. Set
    15. _LetzteAuswertung.Clear()
    16. For Each ele In Value
    17. _LetzteAuswertung.Add(ele.Key, ele.Value)
    18. Next
    19. End Set
    20. End Property


    Viele Grüße

    Bedenke, dass es bei Variante 1 um Verweistypen geht. 2 Klassen können also dasselbe (nicht das gleiche!) Dictionary zugewiesen bekommen. Und wenn eine dann das Dictionary per Clear löscht, ist es bei der 2. Klasse auch leer. Dann lieber Variante 2.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    @Haudruferzappeltnoch Und dann so:

    VB.NET-Quellcode

    1. Set
    2. _LetzteAuswertung.Clear()
    3. _LetzteAuswertung.AddRange(Value)
    4. End Set
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Haudruferzappeltnoch schrieb:

    Wann nutzt ihr nicht-standard Properties?


    Immer dann, wenn sie besser sind als die Standardeigenschaften - z.B. wenn dabei noch Events wie ​PropertyChanged aufgerufen werden müssen.
    Oder wenn eine weitere Prüfung stattfinden muss; existiert der Wert bereits, muss der Wert noch transformiert werden, etc.

    Haudruferzappeltnoch schrieb:

    Ist das sinnvoll oder eher Blödsinn, da die Element ja an sich schon in einem Dictionary existieren?

    Hängt immer ganz davon ab, was genau du erreichen willst.
    In deinem oberen Beispiel ersetzt du den bestehenden Wert mit dem, des neuen. Je nach Objekt ist das dann ein direkter Verweis, meist ist es jedoch eine Kopie.
    Ist ziemlich schnell und der Code zeigt auf einem Blick, was du damit erreichen möchtest.

    Haudruferzappeltnoch schrieb:

    Ich kann wie gewohnt das Dictionary ersetzen oder ich ersetze nur die Elemente.


    Wenn du gleich einen neuen Wert draufgibst, dann kann der vorherige Wert wieder vom GC eingesammelt und freigegeben werden.
    Mit deiner zweiten Variante hast du eine kurze Zeit beide Werte, die nicht freigegeben werden können.

    Was hier zu beachten wäre, ist die Geschwindigkeit.
    Deine zweite Variante ist deutlich langsamer als die erste und wahrscheinlich wird der Compiler das zu der ersten Variante optimieren.

    Was man immer bedenken muss, ist dass Compiler durchaus das Recht haben, deinen Code nicht unerheblich zu verändern, solange das Endergebnis das selbe ist.

    Mal als kleines Anschauungsbeispiel:

    Wenn du:

    C#-Quellcode

    1. ​
    2. for (int i = 0; i < 10; i++) {
    3. Console.WriteLine($"i is { i }");
    4. }


    schreibst, dann wird der Compiler das wahrscheinlich zu:

    C#-Quellcode

    1. ​
    2. Console.WriteLine($"i is { 0 }");
    3. Console.WriteLine($"i is { 1 }");
    4. Console.WriteLine($"i is { 2 }");
    5. Console.WriteLine($"i is { 3 }");
    6. Console.WriteLine($"i is { 4 }");
    7. Console.WriteLine($"i is { 5 }");
    8. Console.WriteLine($"i is { 6 }");
    9. Console.WriteLine($"i is { 7 }");
    10. Console.WriteLine($"i is { 8 }");
    11. Console.WriteLine($"i is { 9 }");
    12. Console.WriteLine($"i is { 10 }");

    optimieren.

    Solche Optimierungen finden immer statt und bei Code wie deinem kann es zu Effekten führen, mit denen du nicht immer rechnest :)
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems
    Meine Privatwebseite: SimonC.eu

    Bitte nicht wundern, wenn meine Aktivitäten im Forum etwas langsamer sind, ich baue gerade mein Nebengewerbe zum Vollgewerbe aus.
    Ich versuche auf euch zurückzukommen :)

    Haudruferzappeltnoch schrieb:

    (...) Ist das sinnvoll oder eher Blödsinn, da die Element ja an sich schon in einem Dictionary existieren?
    Wann nutzt ihr nicht-standard Properties? (...)

    Man nutzt normalerweise etwas, wenn es notwendig ist, sich dadurch ein signifikanter Mehrwert beim Schreiben einer Anwendung für uns ergibt oder es in das schreibtechnische Gesamtkonzept des Programms passt bzw. passen soll oder muss, und nicht, weil es en vogue ist oder generell das Verwenden solcher Begriffe in irgendeiner Szene als „cool” gilt; das trifft auch auf die – insbesondere verbale – mantraartige Wiederholung dieser Begriffe in englischer statt in deutscher Sprache zu, wenn ein „Tutorial/Vortrag” sonst komplett auf Deutsch gehalten wird – in gewissen Kreisen passiert es leider ständig. Nebenbei läuft man dann natürlich auch Gefahr, etwas vollkommen falsch auszusprechen – aber das Vorstellungsvermögen schrumpft ja meistens, wenn man auf so einer Euphoriewelle surft. Das Prinzip des Mehrwerts gilt auch für Vererbung, Polymorphie, Überschreibungen und das gekonnte Ansprechen des Konstruktors der Mutterklasse in Kombination mit der Kindklasse. Die Vergütung des Codes bedeutet nicht immer, ihn komplexer oder komplizierter zu gestalten.
    Das gleichzeitige Erscheinen von Dummheit und Unmündigkeit nach Immanuel Kant ist eines der schlimmsten Dinge, die einem Homo sapiens in geistiger Hinsicht widerfahren können, hat manchmal aber auch durchaus seine Vorteile.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Gregor Jasinski“ ()

    Ich nutze erweiterte Properties tatsächlich häufiger. Wenn ich mit Entitäten arbeite die ich mit einer Zeile speichere, dann baue ich mir Properties die als Zwischenhändler zwischen der Entität und den Controls fungieren. In der Praxis sieht das in etwa so aus:

    Control (Form) --Databinding-> Model -> Entitität

    VB.NET-Quellcode

    1. Public Property Designation As String
    2. Get
    3. If Article IsNot Nothing Then
    4. Return Article.Designation
    5. Else
    6. Return String.Empty
    7. End If
    8. End Get
    9. Set(value As String)
    10. If Article IsNot Nothing AndAlso Not String.Equals(value, Article.Designation) Then
    11. Article.Designation = value
    12. OnPropertyChanged("Designation")
    13. IsModified = True
    14. End If
    15. End Set
    16. End Property


    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Yanbel“ ()

    Es ging aber um Properties, die keinen primitiven Datentyp haben, nicht um solche mit ausgebauten Gettern/Settern.
    btw: bitte VB.NET-Tag nutzen; und Article (z.B. ein Zeitungsartikel) <-> Item (ein Gegenstand)
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Na ich denke, das kann man mehrdeutig verstehen. Nicht-Standard Properties meine ich eigentlich alles, was nicht die Kurzschreibweise verwendet.

    VB.NET-Quellcode

    1. Public Property test as beliebig

    Für die primitiven Datentypen habe ich es bisher nie anders gemacht, daher erwähnte ich die extra.

    Ich denke das man spezielle Klasse auch im Standard nutzt ist nichts Besonderes im Vergleich zu primitiven Datentypen?

    Achso, dann bin ich aber schon in Post#1 falsch abgebogen. Also ist der Diskussionsfokus nicht der Datentyp, sondern die Nicht-Verwendung der Einzeiler-AutoProperty.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    @VaporiZed Danke für den Hinweis. Hab die Tags manuell geändert, weil ich am Anfang aus versehen C#-Tags verwendet hatte. Habs nochmal auf vbnet geändert. Ich hatte das jetzt auch so verstanden, dass es um nicht Auto-Properties ging. Im Endeffekt sind "primitive Datentypen" auch nichts anderes als Klassen. Das hatte ich jetzt nicht als besonders empfunden.

    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.

Facebook
Telefonspende