public vs. internal methods on an internal class

Question

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?

Bekah

@EricLippert blogged his opinion today. ericlippert.com/2014/09/15/internal-or-public/#more-2353 – Bekah

Answer 1

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.

Pops

Answer 2

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.

Udale

Answer 3

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.

Adenitis

These are the kind of dirty details I'm always interested in. Though, generally if someone is using reflection to access hidden members in my classes, I won't worry if it is difficult for them. – Bekah

@Bekah - sometimes you are reflecting over your own types - i.e. where you would normally have access to the internal method, but suddenly you don't. – Adenitis

Answer 4

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.

Rocket

Answer 5

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).

Ninanincompoop

Answer 6

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

Eleanor

Answer 7

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.

Mitch