Is there any constraint to specify the access specifier of members of a class when we have specified access specifier of the class?

Question

Hi Suppose that we have a class named class1.

The class1 has several properties and methods and we have decided to specify the access specifier of class1 as internal.

Now, can we set the access specifier of class1 methods as public?

Answer 1

By rule access specifiers on methods and properties can not be more more accessible than that of the class containing it.

But I've tried this:

internal class Test
{
    public string Testing{get;set;}
}

and it compiles without any exception! I think it is okay as the class Test will not be accessible outside the namespace assembly we have declared so public property will not make any difference.

This does not works:

private class Test
{
    public string Testing{get;set;}
    internal string TestingAgain{get;set;}
}

Answer 2

For your specific question, Class 1 which is declared as internal can have a public method.

Why?

Look at Jon Skeets explanation:

You can certainly mark a class as internal, but that's different from making its public members internal. For instance, suppose you have a class which implements a public interface. Even though the class may be internal, an instance may still "get out of the assembly" by being returned from a member in another (public) class. That instance would have to be referenced by the interface it implements rather than the class name itself (as the class isn't known to the outside assembly) but the public methods can still be called.

If the public methods aren't implementing any interfaces, I suspect it would only make a difference in a very few reflection cases which you may not care about.

community wiki - as credit should go to Jon Skeet

Answer 3

Yes, you can set public on members of internal/private/etc types.

As other replies have noted, external code won't be able to see the properties unless it can see the type - but there are lots of nuances:

• if the member is on an interface it will be (essentially) part of the public API
• the member might be a public override of a virtual/abstract member - in which case it will truly be publicly visible, but via the base-class (again, similar to interfaces)

But there is a lot of other code in the framework that uses reflection and demands public accessibility:

• data binding usually works on the public properties
• security checks for partial-trust can be fussy about public members
• serialization (for example XmlSerializer) may want public members
• etc

So there are still lots of reasons to think about public rather than just internal, even if your code is only referenced by the local assembly.