Ich finde oft, dass ich eine Eigenschaft schreibe, die träge bewertet wird. Etwas wie:
%Vor%Es ist nicht viel Code, aber es wird oft wiederholt, wenn Sie viele Eigenschaften haben.
Ich denke darüber nach, eine Klasse namens LazyProperty zu definieren:
%Vor%Damit könnte ich ein Feld wie folgt initialisieren:
%Vor%Und dann könnte der Körper der Eigenschaft reduziert werden auf:
%Vor%Dies würde von den meisten Unternehmen verwendet werden, da es in eine gemeinsame Klassenbibliothek gehen würde, die von den meisten unserer Produkte gemeinsam genutzt wird.
Ich kann nicht entscheiden, ob das eine gute Idee ist oder nicht. Ich denke, die Lösungen haben einige Vorteile, wie:
Auf der anderen Seite wäre es schwieriger, den Code zu betrachten und genau zu bestimmen, was passiert - vor allem, wenn ein Entwickler mit der LazyProperty-Klasse nicht vertraut ist.
Was denkst du? Ist das eine gute Idee oder sollte ich es aufgeben? Ist der implizite Operator auch eine gute Idee, oder möchten Sie die Value-Eigenschaft explizit verwenden, wenn Sie diese Klasse verwenden?
Meinungen und Vorschläge sind willkommen: -)
Nur um zu pedantisch zu sein:
Ihre vorgeschlagene Lösung, um zu vermeiden, Code zu wiederholen:
%Vor%Sind eigentlich mehr Zeichen als der Code, den Sie nicht wiederholen wollten:
%Vor%Abgesehen davon denke ich, dass die implizite Besetzung den Code sehr schwer verständlich macht. Ich hätte nicht gedacht, dass eine Methode, die einfach zuerst zurückkehrt, letztendlich ein HeavyObject erzeugt. Ich hätte zumindest die implizite Umwandlung fallen gelassen und zuerst zurückgegeben. Wert von der Eigenschaft.
Mach es gar nicht.
Im Allgemeinen ist die Verwendung dieser Art von lazy-initialisierten Eigenschaften in einem Fall eine gültige Entwurfsauswahl: wenn SomeOperation(); eine teure Operation ist (in Bezug auf E / A, wie wenn ein DB-Treffer oder rechnerisch benötigt wird) UND wenn Sie sind sicher, dass Sie oft nicht darauf zugreifen müssen.
Das heißt, standardmäßig sollten Sie eifrig initialisieren, und wenn Profiler sagt, dass es Ihr Flaschenhals ist, dann ändern Sie es in faule Initialisierung.
Wenn Sie das Bedürfnis verspüren, diese Art von Abstraktion zu erschaffen, ist das ein Geruch.
Sicherlich möchten Sie zumindest, dass LazyPropery<T> ein Werttyp ist, andernfalls haben Sie für jede "lazy-loaded" -Eigenschaft in Ihrem System Speicher- und GC-Druck hinzugefügt.
Was ist mit Szenarien mit mehreren Threads? Stellen Sie sich zwei Threads vor, die gleichzeitig die Eigenschaft anfordern. Ohne Sperren könnten Sie möglicherweise zwei Instanzen der zugrunde liegenden Eigenschaft erstellen. Um eine Sperrung im Normalfall zu vermeiden, sollten Sie ein doppelt geprüftes Schloss verwenden.
Ich bevorzuge den ersten Code, weil a) es ein so allgemeines Muster mit Eigenschaften ist, dass ich es sofort verstehe, und b) der Punkt, den du angesprochen hast: dass es keine versteckte Magie gibt, die du nachsehen musst, um zu verstehen, wo und wenn der Wert erhalten wird.
Ich mag die Idee, dass es viel weniger Code und eleganter ist, aber ich wäre sehr besorgt über die Tatsache, dass es schwer wird, es zu sehen und zu erzählen, was vor sich geht. Die einzige Möglichkeit, die ich in Betracht ziehen würde, ist eine Konvention für Variablen, die auf die "faule" Art und Weise gesetzt werden, und auch, wo immer sie benutzt wird, zu kommentieren. Jetzt wird es keinen Compiler oder irgendetwas geben, das diese Regeln durchsetzt, also immer noch YMMV.
Letztendlich gehen solche Entscheidungen für mich dahin, wer sie betrachten wird und welche Qualität diese Programmierer haben. Wenn Sie Ihren Mitentwicklern vertrauen können, sie richtig zu benutzen und gut zu kommentieren, dann sollten Sie es tun, aber wenn nicht, ist es besser, wenn Sie es auf leicht verständliche und nachvollziehbare Weise tun. / meine 2cents
Ich glaube nicht, dass es beunruhigend ist, dass ein Entwickler, der nicht versteht, ein gutes Argument gegen etwas wie das ist ...
Wenn du denkst, dass du dann nichts tun könntest aus der Angst, dass jemand nicht versteht, was du getan hast
Sie könnten ein Tutorial oder etwas in einem zentralen Repository schreiben, wir haben hier ein Wiki für diese Art von Notizen
Alles in allem denke ich, dass es eine gute Idee für eine Implementierung ist (ich möchte keine Debatte starten, ob Lazyloading eine gute Idee ist oder nicht)
In diesem Fall erstelle ich ein Visual Studio-Code-Snippet . Ich denke, das sollten Sie wirklich tun.
Wenn ich beispielsweise ASP.NET-Steuerelemente erzeuge, habe ich oft Daten, die sehr oft in ViewState gespeichert werden. Daher habe ich ein Code-Snippet wie folgt erstellt:
%Vor%Auf diese Weise kann der Code leicht mit wenig Aufwand erstellt werden (Typ, Schlüssel, Name und Standardwert definieren). Es ist wiederverwendbar, aber Sie haben nicht den Nachteil eines komplexen Codes, den andere Entwickler vielleicht nicht verstehen.
Ich mag Ihre Lösung, da sie sehr clever ist, aber ich denke nicht, dass Sie viel gewinnen, wenn Sie sie verwenden. Lazy das Laden eines privaten Feldes in einer öffentlichen Eigenschaft ist definitiv ein Ort, an dem Code dupliziert werden kann. Das ist mir jedoch immer als ein Muster aufgefallen, das ich anstelle von Code verwenden muss, das in einen gemeinsamen Ort umgestaltet werden muss.
Ihr Ansatz könnte in Zukunft ein Problem werden, wenn Sie eine Serialisierung durchführen. Außerdem ist es zunächst verwirrender zu verstehen, was Sie mit dem benutzerdefinierten Typ machen.
Insgesamt applaudiere ich Ihrem Versuch und schätze seine Klugheit, würde aber vorschlagen, dass Sie aus den oben genannten Gründen zu Ihrer ursprünglichen Lösung zurückkehren.
Ich persönlich denke nicht, dass die LazyProperty-Klasse, wie sie ist, genug Wert bietet, um ihre Verwendung zu rechtfertigen, besonders unter Berücksichtigung der Nachteile, die sie für Werttypen hat (wie Kent erwähnt). Wenn Sie andere Funktionen benötigen (z. B. Multithread), könnte dies als ThreadSafeLazyProperty-Klasse gerechtfertigt sein.
In Bezug auf die implizite Eigenschaft mag ich die Eigenschaft "Wert" besser. Es ist ein bisschen mehr Tipparbeit, aber viel klarer für mich.
Ich denke, das ist eine interessante Idee. Zuerst würde ich empfehlen, dass Sie die Lazy-Eigenschaft vor dem aufrufenden Code verstecken. Sie wollen nicht in Ihr Domänenmodell eindringen, dass es faul ist. Was du mit dem impliziten Operator machst, behalte das so.
Ich mag es, wie Sie mit diesem Ansatz die Details der Sperrung behandeln und abstrahieren können. Wenn Sie das tun, dann denke ich, dass es Wert und Verdienst gibt. Wenn Sie Locking für das Double Lock-Muster hinzufügen, ist es sehr einfach, es falsch zu verstehen.
Sie können C # Iteratoren verwenden. Der folgende Beitrag erklärt eine Beispielverwendung und die Vorteile bei der Verwendung.
Tags und Links .net c# lazy-evaluation