わかりました、これは少しばかげた質問かもしれません、そして確かに明白な答えがありますが、私がここで微妙なところを見逃したかどうか私は興味がありました。
public
クラスで宣言されたinternal
メンバーとinternal
クラスで宣言されたinternal
メンバーの可視性/使いやすさの点で違いはありますか?
つまり、
internal class Foo
{
public void Bar()
{
}
}
そして
internal class Foo
{
internal void Bar()
{
}
}
メソッドをpublic
およびvirtual
として宣言し、派生クラスのpublic
でオーバーライドした場合、この修飾子を使用する理由は明らかです。しかし、これが唯一の状況ですか...他に何か不足していますか?
このケースを考えてみましょう:
public interface IBar { void Bar(); }
internal class C : IBar
{
public void Bar() { }
}
ここでは、C.Barを内部としてマークすることはできません。 C.BarはD.GetBar()の呼び出し元からアクセスできるため、これを行うとエラーになります。
public class D
{
public static IBar GetBar() { return new C(); }
}
public
クラスの場合、internal
メンバーはinternal
のままです。
MSDNから :
メンバーのアクセシビリティは、それを含む型のアクセシビリティを超えることはできません。たとえば、内部型で宣言されたパブリックメソッドには、内部アクセシビリティのみがあります。
このように考えると、私はpublic
プロパティにアクセスします...?見えないクラス? :)
この場合、Ericの回答は非常に重要です。直接ではなく、インターフェースを介して公開されている場合does違いが生じます。あなたが扱っているメンバーとの状況。
WPFでXAMLから使用したときに、これらの2つの間にisの違いがある別の例に直面しました。
XAML:
<Button Tag="{x:Static vm:Foo+Bar.e1}" />
internal
enumを含むコードは正常にコンパイルされます。
internal class Foo
{
internal enum Bar
{
e1,
e2,
}
}
しかし、意外にもpublic
に変更すると、エラーが発生します。
internal class Foo
{
public enum Bar
{
e1,
e2,
}
}
最後の例ではコンパイルエラーが発生します。
エラーMC3064:マークアップ内で使用できるのはパブリッククラスまたは内部クラスのみです。 「バー」タイプはパブリックまたは内部ではありません。
残念ながら、この場合のpublic
の何が問題なのか説明できません。私の推測は、「WPFがそのように機能するからといって」です。ネストされたクラスの修飾子をinternal
に変更するだけで、エラーを取り除くことができます。
リフレクションに関しては、メンバーがパブリックであるかどうかが重要です。
たとえば、ネストされたプライベートクラスをWPFバインディングに渡すこともでき、バインディングは通常どおりパブリックプロパティに対して機能します。
public
クラスのinternal
メンバーは、public
基本クラスのpublic
メンバーをオーバーライドできるため、間接的に表示される場合は、もう少し公開されます。