2

私は、「リフレクションを使用する開発者のエクスペリエンスを向上させる」ことを目的としたFasterflectというライブラリに貢献しています。そのため、従来のリフレクションの上に構築された抽象化を提供し、まったく同じシナリオで使用されます。

次に、オブジェクトインスタンスを介してメンバーにアクセスするための現在の構文を示します。

obj.SetPropertyValue( "PropertyWithPrivateSetter", "foo" );
obj.SetFieldValue( "_readOnlyIntegerProperty", 123 );

あるユーザーは、lamdbaベースのアクセスのサポートを追加することを提案しました（Fluent Hibernateと同様）。

obj.SetPropertyValue<MyClass>( x => x.PropertyWithPrivateSetter, "foo" );
obj.SetFieldValue<MyClass>( x => x.ReadOnlyInteger, Access.CamelCaseField(Prefix.Underscore), 123 );

コンパイル時に知らない型に対してリフレクションが通常実行されることを考えると、これが役立つシナリオを考えるのに苦労しています。私は想像力に欠けているだけですか？コンパイル時にタイプがわかっているリフレクションの有効なシナリオはありますか？

このNBuilder機能リクエストには、元の提案に対する追加のコンテキストがいくつかあり、 Fasterflect機能リクエストを表示することもできます。

4

2 に答える 2

3

主な使用シナリオは、あなたが説明するシナリオです。パブリックゲッターがあり、プライベートセッターがあるプロパティ。ラムダ式を使用することで、プロパティ名のコンパイル時チェックを提供します（つまり、マジックストリングはありません）が、リフレクションを介して「読み取り専用」プロパティを設定する方法を提供します。

于 2010-03-29T19:47:29.523 に答える
0

リードが言ったこと（私が入力したものよりも簡潔に言った）を拡張するために、これの非常に有効なシナリオの1つは、真の読み取り専用コンテキストを提供するラッパーまたは読み取りのセットアップを提供するラッパーを解約する「読み取り専用ファクトリ」です。 -オブジェクトのみで、コンストラクターのセットアップ（つまり、真の封印されたクラス）を回避します。

于 2010-03-29T19:55:56.713 に答える