Chargify.NETというAPIラッパーを作成しましたが、.NET4をターゲットにすることで解決できる可能性のあるパターンが開発され始めています。
問題は、APIが強化されるにつれて、1つの特定のアクション（この場合はサブスクリプションの作成）を処理するために、オーバーロードされた関数をますます作成する必要があることです。現在、私は多くの（多すぎると思う）オーバーロードされたCreateSubscription関数を持っており、さまざまな署名を管理するのが難しくなっています。
.NET 4に対してライブラリを構築し、オプションのパラメータを使用して、ライブラリのユーザーが.NET 4ライブラリを使用できることを期待することは可能（および/または提案）ですか？それとも、3.5を使用しているパスに沿って続行する必要がありますか？またはどういうわけか両方をターゲットにしますか？
これについての議論が必要です..
本当に正しい答えはありません。.NET 4機能の使用を開始する場合は、.NET 4のみをターゲットにすることをお勧めします。両方をターゲットにしようとすると、古い機能に制限されるか（アップグレードする理由がない）、2つのコードパスが必要になる（メンテナンスに悪い）ためです。 。
.NET 4を使用すると、ターゲット市場が.NET 4を使用している人々に限定されます。新機能に伴う追加の柔軟性とパワー、および簡略化されたAPI（つまり、オプションのパラメーター機能）が視聴者を制限する価値があります。
オーディエンスがコマーシャルショップの場合、これは大きな問題になる可能性があります。ターゲットユーザーが小規模な開発者、または主に他のオープンソース開発者である場合、ラッパーを使用するために.NET4にアップグレードすることをいとわない可能性があります。必要。
オプションのパラメータは、4.0よりかなり前の.NETで完全にサポートされていました。ただし、C＃から言語サポートを取得したのはごく最近のことです。オプションのパラメーターは、CLS準拠の言語で完全にサポートされている必要はないことに注意してください。コンパイラーは、指定されたデフォルト値を無視できます。
ご存知のとおり、C＃コンパイラがプログラムをコンパイルし、プログラムがオプションのパラメータを使用する場合、コンパイラが行うのは、オーバーロードされた関数の代わりにそれらのオプションのパラメータを使用することだけです。したがって、オプションのパラメータに切り替えることで、速度やコード削減のメリットは得られません。