internal class Foo
{
public void Fee()
{
Debug.WriteLine("Fee");
}
internal void Fi()
{
Debug.WriteLine("Fi");
}
}
クラス全体がすでに内部にあるため、Fee()とFi()は等しくアクセス可能であると考えています。私は何かを見落としていますか?このような場合にメソッドにパブリックまたは内部を選択する理由はありますか?
_internal class Foo
_宣言は、public void Fee()
メソッドのアクセス可能性をオーバーライドし、事実上それを内部にします。
この場合、メソッドで内部vsパブリックを使用しても同じ効果があります。このような場合にパブリックメソッドと内部メソッドを選択する唯一の理由は、将来のバージョンでパブリッククラスに簡単に移行できるようにするためです。
答えでここに欠けている唯一のものは、なぜあなたはこれをするのですか?
一部のライブラリには、ライブラリのコンシューマが触れることを意図していないクラスが多数ありますが、パブリックとしてマークされたインターフェイスを継承する必要があります。たとえば、IComparerインターフェイスを継承するクラスを持つライブラリがありますが、それは内部でのみ使用され、ライブラリのパブリックな側面を混乱させたくありません。実装されたCompare関数を内部としてマークすると、コンパイラはインターフェイスIComparerを実装していないと文句を言います。
それでは、どのようにしてインターフェイスを正常に実装し、同時にライブラリのパブリックな側面からアクセスできないようにするのでしょうか?クラスを内部としてマークしますが、実装された関数はパブリックとしてマークします。
実際には、リフレクションを使用している場合は大きな違いがあります。特に、リフレクションを介して内部メソッドにアクセスしようとすると、Silverlightは非常に怒ってしまいます。通常の.NETで機能していても、Silverlightでコードを機能させるためにメソッドをパブリックにする必要がある場合があります。
通常の.NETの部分信頼でも同じことがわかります。
内部クラスでインターフェースを実装する場合、違いが生じます。何らかのインターフェイスの実装であるメソッドは、パブリックである必要があります。
あなたは正しいです、料金とFiの両方が等しくアクセス可能になります。
3.5.2の下のCSharp Language Specification 3.0から:
プログラムP内の型Tで宣言されたネストされたメンバーMのアクセシビリティドメインは、次のように定義されます(M自体が型である可能性があることに注意してください)。
•Mの宣言されたアクセシビリティがパブリックである場合、MのアクセシビリティドメインはTのアクセシビリティドメインです。
したがって、Feeがパブリックとして宣言されている場合でも、Foo(つまり、内部)と同じようにアクセスできます。
msdn documentation によると、Fooクラスはアセンブリの外部からアクセスできないため、メソッドを内部またはパブリックとしてマークしても違いはありません。属性InternalsVisibleToを使用しても違いはありません
クラスが内部の場合は、内部メソッドのみを使用します。気が変わってクラスを公開する場合は、テキストを置き換えるだけで完了です。