たくさんのタイプを他のタイプの束に変換したいと思います。たとえば、、、、の4つのタイプがありSourceA
、次の変換があります。SourceB
TargetA
TargetB
- SourceA => TargetA
- SourceA => TargetB
- SourceB => TargetA
- SourceB => TargetB
基本的に、変換は単純なキャストよりも少し高度です。上記の各ケースについて、独自の戦略が必要です。
私が避けたいのは、メソッド名に型を含むいくつかのメソッドがあることです。そのため、次のようなものは必要ありません。
ConvertAtoA
または同様のもの。これが不要な理由は、型が型自体としてではなく文字列として使用されるためです。したがって、型の名前を変更しようとすると、リファクタリングはサポートされません。名前をに変更SourceA
するSourceXyz
と、メソッドの名前は自動的に変更されませんが、手動で変更する必要があります。
私が欲しいのは、主にリファクタリングのサポートを得るために、これを表現する一般的な方法です。つまり、基本的に次のようなものです。
Convert<SourceA, TargetA>(mySourceValue)
ここでの問題は、すべての型のすべてのロジックを含むジェネリックメソッドになっConvert<TSource, TTarget>
てしまうことです(これは明らかな理由から悪い考えです)。
訪問者、戦略、責任の連鎖など、さまざまなデザインパターンをすでに見てきましたが、どれも魅力的ではありませんでした。とにかく、そこのポイントを逃したかどうかはわかりません。
どうすればこの問題を解決できますか?
基本的に、2つの主なターゲットは次のとおりです。
- 組み合わせごとに個別の変換ロジックを持つ(複雑なメソッドはありません)
- リファクタリングのサポートがある(文字列としてのタイプなし)
何か案は?
アップデート1: AutoMapperの使用を検討しましたが、希望どおりに機能するかどうかわかりません。私が確実にできることは、次のようなカスタムコンバーターをセットアップすることです。
Mapper.CreateMap<string, DateTime>().ConvertUsing(new DateTimeTypeConverter());
DateTime
しかし、ここでも、コンバーター名の一部としてタイプがあります。ここでもラムダ式を使用できることは知っていますが、コードが非常に長くなるため、コードが醜くなります。とにかく、私はすべてを手に入れることができないのではないかと恐れています...
更新2:Dictionary<string, string>
左側に(内容は異なりますが)常に(内容は異なりますが)右側にカスタムクラスがあるという制約を課すことで、問題を緩和できます。だから私が最終的にしたいのは、次のような拡張メソッドです
dictionary.To<TargetA>()
ただし、さまざまなタイプに変換するためのすべてのロジックをTo<T>
メソッドに組み込む必要はありません。