public vs. internal methods on an internal class

internal class Foo
{
public void Fee()
{
Debug.WriteLine("Fee");
}


internal void Fi()
{
Debug.WriteLine("Fi");
}
}

I'm thinking that Fee() and Fi() are equally accessible since the entire class is already internal. Am I overlooking something? Is there any reason to choose public or internal for the methods in a case like this?

27133 次浏览

The internal class Foo declaration will override the accessibility of the public void Fee() method, effectively making it internal.

In this case, using internal vs. public on the methods will have the same effect. The only reason I would choose public methods vs. internal methods in a case like this would be to ease transitioning to a public class in a future version, should you choose to do so.

According to the msdn documentation your Foo class won't be accesible outside your assembly, so it doesn't make any difference to mark the methods as internal or public; it even doesn't make difference by using the Attribute InternalsVisibleTo

You are correct, both Fee and Fi will be equally accessible.

From the CSharp Language Specification 3.0, under 3.5.2:

The accessibility domain of a nested member M declared in a type T within a program P is defined as follows (noting that M itself may possibly be a type):

• If the declared accessibility of M is public, the accessibility domain of M is the accessibility domain of T.

So, even if Fee is declared as public, it will be just as accessible as Foo (i.e. internal).

Actually - there is a big difference if you are using reflection; in particular, Silverlight can get very upset if you try and access internal methods via reflection, even if you would have had access. I've seen occasions when I've had to make a method public to make the code work on Silverlight, even though it works on regular .NET.

You might find the same with partial trust in regular .NET.

The only thing missing here in the answer is why would you do this?

Some libraries have a lot of classes that are not meant for the consumer of the library to touch but they must inherit interfaces marked as public. For instance I have a library with a class that inherits the IComparer interface but it is only used internally and I don't want to clutter the public aspect of my library. If I mark the implemented Compare function as internal the compiler complains that I am not implmenting the interface IComparer.

So how do I successfully implement the interface and at the same time prevent it from being accessible in the public aspect of my library? Mark the class as internal but the implemented function as public.

I would go with only internal methods if a class is internal. in case you change your mind and make the class public you can just do a text replace and you are done.

It would make a difference when you want your internal class to implement an interface. The method which is an implementation of some interface, would have to be Public.