derived class accessibility

后端 未结 4 1746
有刺的猬
有刺的猬 2021-01-04 13:49

Why in C# it is not allowed for derived classes to have greater accessibility than its base class.

For example this will give error : Inconsistent accessibility: bas

相关标签:
4条回答
  • 2021-01-04 14:22

    This way, it would be trivial to use a class marked as internal or private as if it were public, by just doing an empty override, just like you did in your example. This would defeat the purpose of marking classes anything other than public at all.

    0 讨论(0)
  • 2021-01-04 14:31

    internal is not the same as package private in Java. The user of DerivedClass may not have or have access to the DLL that BaseClass is in so DerivedClass can't depend on it. Package privacy is a much looser concept in Java - but in your example, DerivedClass would have to be in the same package as BaseClass so there's a good chance the client user would have both of those classes so Java allows it.

    0 讨论(0)
  • 2021-01-04 14:35

    Because otherwise you would be expossing the BaseClass members further than intended.

    One example of a problem would be public const int Age. This is ok because it is only expossed within the same assembly, so versioning is safe. If you now use inheritence to make the class public you are exposing this const field outside of the assembily. This could cause errors if the value is ever changed.

    Often I make a class internal so that I don't have to worry so much about versioning it's public interface in the future. I am free to change it at any time and as long as that one assembily compiles it is ok. If someone came along and expossed it publicly, I would now have to resepect that public interface forever.

    0 讨论(0)
  • 2021-01-04 14:43

    UPDATE: This question was the subject of my blog on November 13th 2012. Thanks for the great question!

    Why in C# it is not allowed for derived classes to have greater accessibility than its base class?

    In addition to the other good answers, consider this scenario. You and your coworker Alice are working on different parts of the same assembly. Alice writes a class:

    public class ComplicatedClass
    {
        public void DoDangerousThing() { ... }
    }
    

    You then write

    public class EvenMoreComplicatedClass : ComplicatedClass
    {
    }
    

    Great. Now Alice gets a security review from Bob, and they realize that (1) no customer ever needs to use ComplicatedClass, and (2) DoDangerousThing exposes a security hole that hostile code could take advantage of. Internal code of course does not.

    So Alice changes her code to

    internal class ComplicatedClass
    {
        public void DoDangerousThing() { ... }
    }
    

    Figuring there is no need to change "public" to "internal" on the method because of course public means "public to things that can see this class", and now no external code can see this class.

    What should happen to your code when Alice recompiles with this change? It should fail to compile. You have made an assumption that users need to see the base class, and Alice has made a change that violates that assumption. The safe thing to do is for the compiler to tell Alice that she needs to come talk to you so that you can resolve this problem without exposing the customer to the vulnerability of DoDangerousThing.

    Why it is allowed in Java?

    No idea, sorry.

    0 讨论(0)
提交回复
热议问题