سؤال

I am reading book "C# 4.0 in a nutshell" by Joseph Albabari and Ben Albabari. From there I find a topic restrictions on access modifiers. Page 91, Topic "Restrictions on Access Modifiers".

Quoting from the book.

The compiler prevents any inconsistent use of access modifiers. For example, a sub- class itself can be less accessible than a base class, but not more

So this says that base class should be equally or more accessible than subclass. So if base class is internal then subclass should be either private or internal. If base class is private and sub class is public then compile time error will be generated. While trying this in Visual Studio I found some strange behavior.

Try 1: Base is private and sub class is private (Works, right behavior) This also works if both are internal, public.

private class A { }
private class B : A { }         // Works

Try 2: Base is private and sub class is public or internal (This fails, right behavior)

private class A { }
public class B : A { }          // Error

Try 3 : Base is internal and sub is public (This works, but it should fail. As Base is less accessible than sub class

internal class A { }
public class B : A { }          // Works, but why

Now my question is why Try 3 didn't failed? Sub class is public and is more accessible than base class which is internal. Even the book says this should fail. But Visual Studio compiled this successfully. This should work or not?

Edit:

I created a new Console Project in VS. In Program.cs I added my code. Here is complete code of Program.cs file.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;

namespace ConsoleApplication
{
    class Program
    {
        internal class A { }
        public class B : A { }          // Error

        static void Main()
        {
        }
    }
}
هل كانت مفيدة؟

المحلول

You are placing your nested classes within another internal class.

For example, given:

class Program
{
    static void Main(string[] args)
    {
    }

    internal class A { }
    public class B : A { }
}

It will compile because the internal modifier of the wrapping class makes the public modifier on class B moot. Rather, type B's accessibility is limited by its wrapped class Program -- its accessibility domain is internal as well.

If you update it to be:

class Program
{
    static void Main(string[] args)
    {
    }
}

internal class A { }
public class B : A { }

It will throw the inconsistent visibility compiler error. Or if you redefine Program to be public instead of internal it will also throw the error. In this case, B's accessibility domain is now public and no longer limited by Program's internal accessibility domain.


From the C# specification 3.5.2 Accessibility Domains:

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.

And the MSDN's description of Accessibility Domain:

If the member is nested within another type, its accessibility domain is determined by both the accessibility level of the member and the accessibility domain of the immediately containing type.

If the wrapping type Program is internal, then the nested type B being public will have its accessibility to match Program, thus it is treated as internal and no compiler error is thrown.

نصائح أخرى

private inherited classes can not accessible in other classes when you inherit private class with other public class then it contains the reference of private class and its data so it is not possible.

abstract class test
    {
        public abstract void add();
        public int num1;
        public string str;
    }
class test3 : test1
    {
        public override void add()
        {
            throw new NotImplementedException();
        }
    }

both classes are private. if you use internal then you can access only in assembly.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top