Können Sie auf diesem One-Liner andere Nachteile sehen als die Tatsache, dass mehrere Verwendungen die DRY Prinzip? Es scheint einfach, aber die Tatsache, dass ich nicht gesehen habe, dass andere es vorschlagen, lässt mich fragen, ob es einen Nachteil gibt.
Dieses Codebeispiel erstellt eine WeakReference für eine Methode und registriert dann ein Ereignis Handler, der das Ziel der Referenz aufruft.
%Vor%Danke, Danke Ben
Ich glaube nicht, dass dieses Muster das tut, was Sie erwarten. Möchten Sie verhindern, dass das Ereignis einen Verweis auf das aktuelle Objekt enthält, um Speicherlecks zu vermeiden? Der Lambda-Ausdruck erfasst den Wert von this , um ProcessEvent auszuwerten (unter der Annahme, dass ProcessEvent eine Instanzmethode ist), sodass das Leck weiterhin besteht. Dieser Code ist identisch mit SomeEvent += (sender, e) => ProcessEvent(); .
Sie könnten versuchen, etwas mehr so zu machen (was auch nicht das ist, was Sie wollen):
%Vor% Jetzt wird der Lambda-Ausdruck die WeakReference erfassen, so dass Sie keinen starken Verweis auf this haben. Leider verweist nichts anderes auf den Delegaten, der aus ProcessEvent erstellt wurde, daher wird er auch beim nächsten GC entfernt, selbst wenn this noch aktiv ist. (Dies überprüft auch nicht, ob das Ziel null ist).
Sie könnten so etwas ausprobieren:
%Vor%und benutze es dann so:
%Vor%Dies wird einen schwachen Verweis auf den Empfänger von ProcessEvent behalten und den Ereignishandler automatisch aus dem Ereignis entfernen, nachdem er gesammelt wurde, was Speicherverluste verhindern sollte, solange das Ereignis regelmäßig ausgelöst wird.
Es ist nicht sehr lesbar. Und wenn Sie es debuggen müssen, indem Sie durchgehen, könnte eine dieser Aktionen fehlschlagen, aber diese einzelne Zeile würde fehlschlagen. Außerdem erhalten Sie nur diese einzelne Zeile, auf die in einem Stack-Trace verwiesen wird.
Im Allgemeinen sollten Sie vermeiden, zu viele Dinge in einer einzigen Zeile für die Wartbarkeit zu tun.
Tags und Links .net c# lambda event-handling weak-references