私は現在、PCに接続されたデバイスで構成値を読み取って設定できるライブラリに取り組んでいます。各構成フィールドは、定数（public static readonly）オブジェクトによって記述されます。このオブジェクトには、このフィールドの名前、データのタイプ（値の制限とともに）、および読み取り/書き込みに必要なコマンドシーケンスが含まれています。
この情報は、ほとんどの場合、ライブラリ内で必要になります。ただし、クライアントコードは、特定のフィールドの読み取り/書き込みをライブラリに指示できる必要があります。また、フィールドを値に関連付けるディクショナリで構成値のコレクションを渡したいと思います。これを行うには、フィールドを識別するパブリック値を提供する必要があります。
フィールドを内部的に記述し、それらを公に識別するために同じオブジェクトを使用しても大丈夫ですか？少し違和感がありますが、理由がわかりません。疑問を投げかけるか、なぜそれが悪い考えなのか、何に注意すべきかを教えていただければ幸いです。
更新：フィールドIDとフィールドアクセスの実装の両方に同じオブジェクトを使用することになりました。さて、数か月後、私はついに、これが完全にクリーンなソリューションではなかった理由を浮き彫りにする問題に遭遇しました。前述のように、フィールドオブジェクトはデバイスの構成フィールドを表します。これは、そのようなフィールドへのアクセス方法とは無関係です。
より一般的な言葉で言えば、物事の私の隠された内部表現は物事を説明していません。それは必ずしも1：1の関係を持っていないものに関連する何かを説明します。
フィールドアクセスを変更する場合、これは問題になる可能性があります。たとえば、「エラー時に再試行」アクセス動作を提供するFieldデコレータクラスを作成できなくなりました。デコレータを操作するコードは、実際の基になるフィールドとは関係なく、それを独自のフィールドとして扱います。
これは元の質問に対する答えではなく、私の仮定が間違っていたことの認識であることに注意してください。モノの内部記述がモノ自体と1：1の関係にあると本当に確信している場合、この問題は当てはまりません。