6

最近、特定のロジックを処理し、特定のライフサイクルを持つシリアル化可能なオブジェクトを作成しています。正しく機能するためには、必須の引数を取る適切なコンストラクターでインスタンス化する必要があります。ただし、シリアル化の目的で、パブリックデフォルトコンストラクターも追加する必要があります。

オブジェクトはAPIによって公開され、サードパーティの開発者がインスタンス化して使用できるようになります。そのオブジェクトを正しく操作する方法については適切なドキュメントがありますが、誰かが間違ったコンストラクターを使用したくなるという保証はありません。

サードパーティの開発者がコードを記述しているときに、ガイダンスを適用するための適切な方法を探しています。このObsolete属性が頭に浮かびました。シリアル化コンストラクターにメッセージとして適切なコメントで注釈を付けることができました。メッセージは出力警告に表示され、開発者を正しいコード行に誘導します。また、コンストラクターの使用法は、VisualStudioと使用されるコード検査アドオンの両方によって適切に強調表示されます。

このアプローチで私を悩ませているのは、Obsolete属性の目的がまったく異なることです。意味的な意味は、装飾されたアイテムが非推奨になり、おそらく今後のバージョンで削除されることです。シリアル化コンストラクターのシナリオでは、これは間違っており、この属性の使用法と意味の間に不一致があります。一部の開発部門で有効になっている可能性のある「警告をエラーとして扱う」オプションは言うまでもありません...

だから、問題は-それは属性のそのような使用法のための許容可能な慣行ですか?同じ効果を達成するための他の合法で普遍的な方法はありますか(普遍的には、サードパーティのコード検査アドオンなどに依存しないことを意味します-私はコードを使用する人とその設定を制御しません)?


以下の回答のコメント(これはまだ私には役立ちます)に関して、継承可能なクラスで保護されたデフォルトコンストラクターを使用していることを明確にする必要があります。コンストラクターはXMLシリアル化をサポートするためにありますが、ビジネスロジックでクラスを初期化するために使用しないでください。継承するクラスは他の基本コンストラクターのいくつかを呼び出す必要があり、継承されたクラスを作成する開発者はそれを知る必要があります。それでも、このコードから派生する開発者は、必要に応じて、継承されたクラスのXMLシリアル化を有効にする手段も必要です。

4

1 に答える 1

3

うーん、これは良い解決策ではないと思います。ただし、本当にデフォルトのコンストラクターが必要ですか?

シリアル化APIには、コンストラクターをまったく使用せずに初期化されていないインスタンスを作成するメソッドがあることに注意してください(MSDN:FormatterServices.GetUninitializedObjectを参照)。

また、通常のカスタムシリアル化コンストラクターはデフォルトのコンストラクターではなく、SerializationInfoとStreamingContextを使用するコンストラクターです。カスタムシリアル化がある場合は、デフォルトのコンストラクターを内部にし、シリアル化を実行するアセンブリにInternalsVisibleToAttributeを適用することで問題を解決できる場合もあります。

于 2013-02-10T14:52:06.610 に答える