Why use a public method in an internal class?

Question

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.

If the class is internal, it doesn't matter from an accessibility standpoint whether you mark a method internal or public. However it is still good to use the type you would use if the class were public.

While some have said that this eases transitions from internal to public. It also serves as part of the description of the method. Internal methods typically are considered unsafe for unfettered access, while public methods are considered to be (mostly) free game.

By using internal or public as you would in a public class, you ensure that you are communicating what style of access is expected, while also easing the work required to make the class public in the future.

I often mark my methods in internal classes public instead of internal as a) it doesn't really matter and b) I use internal to indicate that the method is internal on purpose (there is some reason why I don't want to expose this method in a public class. Therefore, if I have an internal method I really have to understand the reason why it's internal before changing it to public whereas if I am dealing with a public method in an internal class I really have to think about why the class is internal as opposed to why each method is internal.

I suspect that "it is easier to make the type public later?" is it.

The scoping rules mean that the method will only be visible as internal - so it really doesn't matter whether the methods are marked public or internal.

One possibility that comes to mind is that the class was public and was later changed to internal and the developer didn't bother to change all the method accessibility modifiers.

In some cases, it may also be that the internal type implements a public interface which would mean that any methods defined on that interface would still need to be declared as public.

It's the same, the public method will be really marked as internal since it's inside a internal class, but it has an advantaje(as you guested), if you want to mark the class as public, you have to change fewer code.

For the same reason as using public methods in any other class - so that they're public to the outside of the containing type.

Type's access modifier has exactly zero to do with its members' access modifiers. The two decisions are made completely independently.

Just because certain combinations of type and members' modifiers produce seemingly (or as others call it "effectively") the same result doesn't mean they're semantically the same.

Local access modifier of a an entity (as declared in code) and its global effective access level (as evaluated through the chain of containment) are completely different things, too. An open office inside of a locked building is still open, even though you can't really enter it from the street.

Don't think of the end effect. Think of what you need locally, first.

• Public's Public: classic situation.
• Public's Internal: type is public but you want some semi-legal access in the assembly to do some hacky-wacky stuff.
• Internal's Public: you hide the whole type but within the assembly it has a classic public surface
• Internal's Internal: I can't think of any real world example. Perhaps something soon to become public's internal?

Internal's Public vs Internal's Internal is a false dilemma. The two have completely different meaning and should be used each in their own set of situations, non-overlapping.