If derived class inherits the private members of a

Question

I want to clear my understanding of this basic OOPS concept in c#. On most of the internet sites, I read that a derived class inherits the private members of a base class, but it cannot access those members.

A derived class has access to the public, protected, internal, and protected internal members of a base class. Even though a derived class inherits the private members of a base class, it cannot access those members. However, all those private members are still present in the derived class and can do the same work they would do in the base class itself. For example, suppose that a protected base class method accesses a private field. That field has to be present in the derived class in order for the inherited base class method to work properly.

Source : http://msdn.microsoft.com/en-us/library/ms173149.aspx

My question is, if we consider above is correct, then can we say "Constructors of base class are inherited in derived class, but derived class can only access/call it through its own constructor using base keyword and this constructor will not be available to outside world while creating instance of derived class".

public class Employee
{
    public int salary;

    public Employee(int annualSalary)
    {
        salary = annualSalary;
    }
}

public class Manager : Employee
{
    public Manager(int annualSalary)
        : base(annualSalary)
    {
        //Add further instructions here.
    }
}

Because to call a base class constructor, it should be present inside that class. Maybe my interpretation is wrong. Can anyone please explain this?

Thanks in advance!

Answer 1

"Constructors of base class are inherited in derived class, but derived class can only access/call it through its own constructor using base keyword and this constructor will not be available to outside world while creating instance of derived class".

Yes, this is correct.

Because to call a base class constructor, it should be present inside that class.

Just like private or protected members of the base, it's "present", but not accesible to the outside.

Answer 2

It depends on how you define "present". If you define it as "somewhere available", private members in base classes are "present" as well as constructors. If you define "present" as "found in that particular class", both are not "present".

Try using reflection. You won't find any private members from base classes. The private members are inherited, thus available, but still only in the base class.

So are constructors.

    class A
    {
        private A(int i) { }
        public A() { }
        private void Foo() { }
        public void Bar() { }
    }

    class B : A
    {

    }

    var aProperties = typeof(A).GetMembers(BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.FlattenHierarchy);
    // you won't see Foo in this line, nor any constructors of A
    var bProperties = typeof(B).GetMembers(BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public  | BindingFlags.FlattenHierarchy);

At the end, you can say:

• All members of base classes are present in terms of somehow available for execution.
• There is no syntax to call private members from inheriting classes (nor from anywhere els outside the class)
• Constructors of the base class can only be called from constructors using the base keyword. (A constructor is always called from each base class in the hierarchy. If not specified, it is the default constructor.)
• Only members that are declared (or overridden) by a class are actually found "inside" that particular class. Using reflection, you can use BindingFlags.FlattenHierarchy to flatten visible members from base classes. Private members and constructors are only found in the declaring class.

Answer 3

in order to construct a Manager you need to construct the base class using any constructor in the base class, if there is only one (as in this case) you need to call it. that does not mean you must define a constructor with the same signature.

you would also be allowed to do this:

public Manager() : base(100000)
{
}

or

public Manager(string name, int salary) : base (salary)
{
     // store name
}

During construction of you Manager you will allocate a new object on the heap. This object will claim enough memory so that it can store the variables defined in the base class (Employee) and concrete class (Manager).

Answer 4

It would be helpful if there were a means by which a class could specify that for every parent-class constructor, the system should infer the existence of a child-class constructor with the same signature and access which does nothing but process field initializers and chain to the corresponding base constructor. Having such a feature available by specific request would be unlikely to cause bugs; even having that be the inference when a derived class doesn't specify any constructors (as opposed to only inferring a parameterless constructor that chains to a base parameterless constructor) would probably be pretty safe if that were a language design feature (adding such a feature to an existing framework, however, would be a bad idea, since the authors of derived classes which want to expose a parameterless constructor but not any parameterized ones might not have included any constructor, with the expectation that the compiler would infer the parameterless constructor only).

If a derived class has any non-trivial constructors of its own, however, it is likely that the child class does not intend for any object to be created without going through one of them. Suppose a parent class has only a parameterized constructor and someone writes:

class Child : Parent
{
   Thing blah;
   Child()
   {
      blah = new Thing();
   }
}

Every Child which is is created will have blah set to a new thing. Now suppose a new version of the base class adds a Name property, and adds a constructor which specifies the name. If constructors were auto-inherited, then code which said myChild = new Child("Fred"); would chain through to the constructor of Parent, but never set blah to a new Thing.

Safe constructor "inheritance" might be made possible if a class could specify a that every instance should be produced by chaining to a parent constructor and then executing a specified block of code to establish child-class invariants. Such a feature would be somewhat complicated to implement, however, and it's unclear that it would be worth the cost.