Ok, so this may be a bit of a silly question, and there's certainly the obvious answer, but I was curious if I've missed any subtleties here.
Is there any difference in terms of visibility/usability between a public
member declared in an internal
class and an internal
member declared in an internal
class?
i.e. between
internal class Foo
{
public void Bar()
{
}
}
and
internal class Foo
{
internal void Bar()
{
}
}
If you declared the method as public
and also virtual
, and then overrode it in a derived class that is public
, the reason for using this modifier is clear. However, is this the only situation... am I missing something else?
Consider this case:
Here C.Bar cannot be marked as internal; doing so is an error because C.Bar can be accessed by a caller of D.GetBar():
Just faced with another example where there is difference between those two, when used from XAML in WPF.
XAML:
Code with
internal
enum compiles successfully:But surprisingly changing it to
public
results in error:The last example produces compilation error:
Unfortunately, I can't explain what's wrong with
public
in this case. My guess is "just because WPF works that way". Just change modifier of the nested class tointernal
to get rid of error.A
public
member is still justinternal
when in aninternal
class.From MSDN:
Think of it this way, I would access a
public
property on....? A class I can't see? :)Eric's answer is very important in this case, if it's exposed via an interface and not directly it does make a difference, just depends if you're in that situation with the member you're dealing with.
If it comes to reflection it matters if the member is public or not:
For example you even could pass a nested private class to a WPF binding and the binding would work against the public properties just as usual.
public
members of aninternal
class can overridepublic
members ofpublic
base classes and, therefore, be a little more exposed... if indirectly.