Why can't I access C# protected members except

问题:

This code:

abstract class C
{
    protected abstract void F(D d);
}

class D : C
{
    protected override void F(D d) { }

    void G(C c)
    {
        c.F(this);
    }
}

Generates this error:

Cannot access protected member 'C.F(D)' via a qualifier of type 'C'; the qualifier must be of type 'D' (or derived from it)

What in the world were they thinking? (Would altering that rule break something?) And is there a way around that aside from making F public?

---

Edit: I now get the reason for why this is (Thanks Greg) but I'm still a bit perplexed as to the rational; given:

class E : C
{
    protected override void F(D d) { }
}  

Why shouldn't D be able to be able to call E.F?

---

The error message is edited so I might have put a typo in there.

回答1:

The "protected" keyword means that only a type and types that derive from that type can access the member. D has no relationship to C therefore cannot access the member.

You have a couple of options if you want to be able to access that member

• Make it public
• Make it internal. This will allow any types to access the member within the same assembly (or other assemblies should you add friend's)
• Derive D from C

EDIT

This scenario is called out in section 3.5.3 of the C# spec.

The reason this is not allowed is because it would allow for cross hierarchy calls. Imagine that in addition to D, there was another base class of C called E. If your code could compile it would allow D to access the member E.F. This type of scenario is not allowed in C# (and I believe the CLR but I don't 100% know).

EDIT2 Why this is bad

Caveat, this is my opinion

The reason this is now allowed is it makes it very difficult to reason about the behavior of a class. The goal of access modifiers is to give the developer control over exactly who can access specific methods. Imagine the following class

sealed class MyClass : C {
  override F(D d) { ... } 
}

Consider what happens if F is a somewhat time critical function. With the current behavior I can reason about the correctness of my class. After all there are only two cases where MyClass.F will be called.

1. Where it's invoked in C
2. Where I explicitly invoke it in MyClass

I can examine these calls and come to a reasonable conclusion about how MyClass functions.

Now, if C# does allow cross hierarchy protected access I can make no such guarantee. Anyone in a completely different assembly can come by and derive from C. Then they can call MyClass.F at will. This makes it completely impossible to reason about the correctness of my class.

回答2:

The reason this doesn't work is because C# doesn't allow cross-hierarchy calling of protected methods. Say there was a class E that also derived from C:

  C
 / \
D   E

Then the reference you're trying to call the method on could actually be an instance of type E and thus the method could resolve at runtime to E.F. This is not permitted in C# as D cannot call E's protected methods, because E is in another branch of the hierarchy, i.e.

var d = new D();
var e = new E();
d.G(e); // oops, now this will call E.F which isn't allowed from D

This makes sense because the keyword protected means the member "is accessible within its class and by derived class instances" and E.F is not a member of D.

回答3:

Even though D is inherits from C, D cannot access C's protected members. D can access D's protected (and private!) members, so if you put another instance of D in there instead of C everything would work. But as Greg stated, C could really be something completely different, and because the compiler doesn't know what C really is, it has to prevent D from accessing something D may not actually be able to access.

A series of posts explaining this from the C# compiler's perspective:

• Why Can't I Access A Protected Member From A Derived Class
• Why Can't I Access A Protected Member From A Derived Class, Part Two: Why Can I?

回答4:

This limitation can be bypassed by using a static protected method:

abstract class C
{
    protected abstract void F (D d);

    // Allows calling F cross-hierarchy for any class derived from C
    protected static void F (C c, D d)
    {
        c.F(d);
    }
}

class D : C
{
    protected override void F (D d) { }

    void G (C c)
    {
        // c.F(this);
        F(c, this);
    }
}

This isn't perfect from security point of view (anyone can derive from C), but if all you care about is hiding method F from the public interface of the class C, this trick may be useful.

回答5:

To understand why this kind of behavior makes sense let's consider why we need access modifiers at all in object oriented programming languages. We need them to limit a scope where a particular class member can be used. And that in turn simplifies searching for the usages.

To summarize:

• to find all usages of public member one needs to search through entire project (and this is not enough in case of library that is used by independent developers)
• to find all usages of protected member one needs to search through the container class and all its subclasses
• to find all usages of private member one needs to search through the container class.

So if the compiler allowed to call protected method from superclass in the described way we could end up with cross-hierarchy calling of protected methods as described in this answer. And in such situation one had to search through all the children of the most parent class that defines the member. And that would increase the scope.

PS. The same behavior is implemented in Java.

回答6:

Simply put: accessing an instance's protected member is taken as a public access, even if you try to do so from within a derived class. Hence, it's denied.

---

There are many answers here and there, but none of them made it clear to me "why I can't access the protected members of a parent class from a child". That above is what I understood after looking at my code again after reading these confusing answers.

Example:

class Parent
{
    protected int foo = 0;
}

// Child extends from Parent
class Child : Parent
{
    public void SomeThing(Parent p)
    {
        // Here we're trying to access an instance's protected member.
        // So doing this...
        var foo = p.foo;
    }
}

// (this class has nothing to do with the previous ones)
class SomeoneElse
{
    public void SomeThing(Parent p)
    {
        // ...is the same as doing this (i.e. public access).
        var foo = p.foo++;
    }
}

You'd think you'd have access to p.foo because you're inside a child class, but you're accessing it from a instance, and that's like a public access, so it's denied.

You're allowed to access protected members from within the class, not from an instance (yes, we know this):

class Child : Parent
{
    public void SomeThing()
    {
        // I'm allowed to modify parent's protected foo because I'm
        // doing so from within the class.
        foo++;
    }
}

Finally, for the sake of completeness, you are actually able to access an instance's protected and even private members only if you're doing so within the same class:

class Parent
{
    protected int foo = 0;

    private int bar = 0;

    public void SomeThing(Parent p)
    {
        // I'm allowed to access an instance's protected and private
        // members because I'm within Parent accessing a Parent instance
        var foo = p.foo;
        p.bar = 3;
    }
}

回答7:

Yes, it is possible. We will most probably have such an example very soon.

To do that you must do the following:

1. Inherit the default form (EditAppointmentDialog) and do your customization (you can even use the winforms designer for that).

public partial class CustomAppointmentEditDialog : EditAppointmentDialog { private RadComboBox cmbShowTimeAs = null;

    public CustomAppointmentEditDialog() 
    { 
        InitializeComponent(); 

        this.cmbShowTimeAs = this.Controls["cmbShowTimeAs"] as RadComboBox; 
    } 

    private void chkConfirmed_ToggleStateChanged(object sender, StateChangedEventArgs args) 
    { 
        this.cmbShowTimeAs.SelectedValue = (args.ToggleState == ToggleState.On) ? 
            (int)AppointmentStatus.Busy : (int)AppointmentStatus.Tentative; 
    } 
} 

In the above code I have added an additional check box and set the status (show time as) of the appointment to Tentative if it is unchecked or to Busy if it is checked. The strange way of accessing the combo box is because it is private currently. This will be changed for the upcoming Q1 2009 release.

2. Subscribe to AppointmentEditDialogShowing event of RadScheduler and substitute the default form with your customized one:

private IEditAppointmentDialog appointmentEditDialog = null;

    protected override void OnLoad(EventArgs e) 
    { 
        base.OnLoad(e); 

        this.radScheduler1.AppointmentEditDialogShowing += new EventHandler<AppointmentEditDialogShowingEventArgs>(radScheduler1_AppointmentEditDialogShowing); 
    } 

    void radScheduler1_AppointmentEditDialogShowing(object sender, Telerik.WinControls.UI.AppointmentEditDialogShowingEventArgs e) 
    { 
        if (this.appointmentEditDialog == null) 
        { 
            this.appointmentEditDialog = new CustomAppointmentEditDialog(); 
        } 
        e.AppointmentEditDialog = this.appointmentEditDialog; 
    } 

I hope this helps. Do not hesitate to write me back if you have further questions.