Why use a public method in an internal class?

UPDATE: This question was the subject of my blog in September 2014. Thanks for the great question!

There is considerable debate on this question even within the compiler team itself.

First off, it's wise to understand the rules. A public member of a class or struct is a member that is accessible to anything that can access the containing type. So a public member of an internal class is effectively internal.

So now, given an internal class, should its members that you wish to access in the assembly be marked as public or internal?

My opinion is: mark such members as public.

I use "public" to mean "this member is not an implementation detail". A protected member is an implementation detail; there is something about it that is going to be needed to make a derived class work. An internal member is an implementation detail; something else internal to this assembly needs the member in order to work correctly. A public member says "this member represents the key, documented functionality provided by this object."

Basically, my attitude is: suppose I decided to make this internal class into a public class. In order to do that, I want to change exactly one thing: the accessibility of the class. If turning an internal class into a public class means that I have to also turn an internal member into a public member, then that member was part of the public surface area of the class, and it should have been public in the first place.

Other people disagree. There is a contingent that says that they want to be able to glance at the declaration of a member and immediately know whether it is going to be called only from internal code.

Unfortunately, that doesn't always work out nicely; for example, an internal class that implements an internal interface still has to have the implementing members marked as public, because they are part of the public surface of the class.

Internal or public?

Suppose we have a sealed internal class C with a member M intended to be accessed from throughout the assembly:

internal sealed class C
{
  ??? void M() { ... }
}

Should the accessibility modifier at ??? be internal or public?

First of all, let’s establish that there is no technical difference between the two. public in C# means “accessible to anyone who can see the class”; making a public member of an internal class does not make the member more accessible than making it internal would.

There are good arguments for both sides.

The pro-internal argument is that the method is effectively internal, and you want to be able to glance at a method declaration and know whether it can be called by external code, whether it needs to be documented, whether it needs to verify that its arguments are valid, and so on.

There are several pro-public arguments. First, let’s state the meanings of the different accessibility modifiers:

private: this member is an implementation detail of the type
protected: this member is an implementation detail of the type hierarchy
internal: this member is an implementation detail of the assembly
public: this member is not an implementation detail at all; it is the public surface

The question then is whether from the point of view of the author of the class, irrespective of the accessibility of the class, is the member logically a part of the public surface, or not? If it is, then make it public.

Another way to say that would be: suppose we marked the member as internal, and then decided to make the class public instead of internal. Would we have to change the member from internal to public in order for the class to function? If the answer is “yes” then it should have been public in the first place.

Finally, other aspects of the language design encourage you to think of public in this way. For example:

internal interface I 
{
  void M();
}
internal sealed class C : I
{
  public void M() { ... }
}

Even though I and C are both internal, the language requires that M be public in order to implement I.M.

As you could probably tell, I am strongly in favour of the “public” option. However there are some members of the C# compiler team that are in the “internal” camp; it’s not an unreasonable position. My advice is to discuss the issue amongst your team, make a decision, and then stick to it. That way you’ll all be able to read and understand the intention of the code.