クラスを internal として定義するとき、通常 public フィールドを internal として定義しますか? それとも公開のままにしますか？内部として設定することにした public/private メソッドを持つ一連のクラスがあります。ここで、クラスの修飾子を internal に変更し、残りのメソッド/プロパティをそのまま (public/private) にするか、(internal/private) に切り替える必要がありますか?
内部に変更することに大きな意味はありません。後で何らかの理由でそれらを公開に戻したい場合は、再び公開に戻す必要があるため、多くの作業が必要になります。
これについて他に考えはありますか？
とにかく、クラスは外部のアセンブリからは見えないため、それらをパブリックのままにしない理由はわかりません。これが問題になると思う唯一のケースは、そのクラスでリフレクションを使用する場合です。
内部のクラスがある場合は、クラス メンバーを public のままにします (もちろん、それがだった場合は protected/private のままにします)。最終的には公開する必要があり、適切なメンバーをすべて public に戻すのは面倒です。
プライベート メンバーを内部に変更すると、アクセスしやすくなるため、絶対に変更しないでください。パブリック メンバーを internal に変更する必要はありません。これは、定義しているアセンブリの外部にあるものは内部クラスへの参照を取得できないためです。
タイプ自体がパブリックである場合と同じように、一般にメンバーに同じ可視性を与えるべきだと思います。
つまり、パブリック API の一部であるメンバーはパブリックである必要があり、「フレンド」クラスにのみ表示される特別な目的のヘルパーであるメンバーは内部である必要があります。
これは、タイプを公開することに決めた場合でも、メンバーの可視性に変更がないことを意味します。
さらに重要なことは、それはあなたの意図を文書化することでもあります - あなたのコードを読んだ人は誰でも、(もしあれば) 内部に意図されたメンバーを特定することができます.
Reflectorを少し掘り下げてみると、BCL自体がこれに関して非常に一貫性がないことがわかります。メンバーがいる多くの内部クラスと、publicメンバーがいる他の多くのクラスが表示されますinternal。いくつかのクラスは、私が識別できる特定の韻や理由なしに、2つを混ぜ合わせて一致させます。
ここには「正しい」答えはありませんが、これについて決定を下す必要があるときはいつでも考慮すべきことがいくつかあります。
internalメンバーは暗黙的にインターフェースを実装することはできず、明示的な実装は常にプライベートです。したがって、クラスインスタンスを介してインターフェイスメンバーにアクセスできるようにする場合（のDisposeメソッドIDisposableは一般的なものです）、それらはパブリックである必要があります。
タイプの可視性は変わる可能性があります。internal将来的には、クラスに外部で利用できるようにしたいいくつかの貴重な機能があると判断するかもしれません。ただし、そうすると、すべてのパブリックメンバーが誰でもアクセスできるようになります。これがあなたが望むものであるかどうかを事前に決定する必要があります。
一方、クラスを作成するもう1つの理由は、internalクラスpublicをサブクラス化する必要があり、派生クラスを別のアセンブリに含める必要があると判断した場合です。この場合、internalメンバーの一部はおそらくprotected internal代わりになるはずです。そうしないと、派生クラスは必要なメンバーにアクセスできなくなります。
結局のところ、結局のところ、他の人が読んで維持するコードを書くことです。修飾子internalは、メンテナンスプログラマーにとって2つの非常に異なることを意味する可能性があります。
外の世界には役に立たないように見えますが、実際には害もありません。典型的な例は、5分で作成され、検証やエラーチェックをあまり行わないユーティリティクラスです。この場合、publicコードを少し厳しくしたり、適切に使用する方法を文書化したりする限り、誰かがそれを作成しても問題ありません。メンバーを作成して、この仮定を明示的にしpublicます。
それは実際には外部消費にとって安全ではないということ。保護された状態を操作したり、ハンドルやトランザクションを開いたままにしたりする場合があります。この場合、internal他の誰もこのクラスを使用してはならないことを完全に明確にするために、個々のメソッドを作成する必要があります。
シナリオに適したものを選択してください。
意図が明確になるように、内部クラスのメンバーには internal キーワードを使用します。ただし、メンバーをパブリックとして定義する必要がある内部インターフェイスを暗黙的に実装すると失敗します。理由はわかりませんが、これは言語仕様の偶発的な間違いであり、対処しなければなりません。