Explain how a private data of a base class can be accessed by publicly derived class?

Answer 1

The only way that private attributes of a base class can be accessed by a derived class (protected or public) is through a protected or public method in the base class.

The protected or public method is the interface through which access to the attributes is defined and controlled.

Answer 2

Yes, but only the protected and public members of the base class are accessible to the derived class. Private members of the base class are only accessible to friends and to other members of the base class. If any private member needs to be accessible to a derived class, you can either declare the member protected (which exposes that member to all derivatives), or declare the derivative a friend of the base class (exposing all private members to just that one derivative), or keep all private data private, and simply provide a protected abstract interface that all derivatives can use. The latter approach is generally the best as it ensures base class encapsulation is maintained.

Answer 3

Java AnswerThis cannot normally be done. Java 1.5 introduced the 'reflection' framework, which allows you to mess with code enough to access these types of things, but this practice is considered to be very poor coding style and should never be done. C++ AnswerIf your derived class is declared to be a friend of the base class, then it can access pretty much anything it wants.

Answer 4

The only way a derived class can ever gain access to the private members of a base class (or any class other than itself, for that matter) is when the derived class is declared a friend of the base class. However, in the real world you would never allow a derived class to gain private access to its own base class. The whole point of having a base class is to provide a common generic interface for all its derivatives. And if a derivative ever needs private access then there's something very wrong with your class design.

As far as indirect access to private members is concerned, the only way this is possible is via the protected or public interface of the base class. However the correct term is abstraction.

Answer 5

The base class only knows about its own members, and those it inherits from other base classes. It knows nothing about any of its derivatives.

The one exception is when the base class declares a virtual function which the derived class overrides. When you call the method on the base class, the virtual table (v-table) automatically redirects the call to the most-derived class method, if one exists.

Even if an overridden method exists, the base class still has no knowledge whatsoever of that method's implementation, nor which derived class that method belongs to. The base class merely provides an interface to that implementation. However, having obtained an interface to the derived class, the derived class itself has unrestricted access to any member in that class.

Although it is possible to embed knowledge of a derived class in a base class by including the derived class declaration in the base class and then dynamically casting the base class to its derived class, this is a sign of poor design. The whole point of having a base class in the first place is to provide a common interface to its derivatives, to allow new derivatives to be created whenever required, without any need to alter the base class in any way. Updating a base class every time a new derivative is created is not only a maintenance headache, dynamic casting is an expensive and completely unnecessary overhead. Virtual methods are specifically designed to avoid these problems.

Answer 6

Ordinarily, no. Private members of the base class cannot be inherited by derived classes (only protected and public members can be inherited). If you have no access to the base class source code, then the only way to access private data is via the protected or public interfaces provided. If you do have access to the source code, you could declare the derived class to be a friend of the base class. However, this is rarely a good idea. Ideally, base classes that are intended to be derived from should never require knowledge of their derivatives, and that includes friendship. The only real exception to that rule is when declaring final classes, where the base class has a private constructor (which is only accessible to friend classes) and the friend classes use virtual inheritance (the friend classes cannot be derived from and are therefore final). If a derivative requires private access for any other reason then you must question why the members are private in the first place. Typically it is to enable encapsulation and the interface should be abstract enough to cater for any derivative, polymorphically, not to cater for specific derivatives. In most cases, a protected or public interface would be the preferred option to a derived friendship.

Answer 7

A derived class cannot change how any base class data member is constructed, that is solely determined by the data members themselves. Even a class that contains member data cannot change how its own members are constructed. It would be a crazy world if one class could change how another class is constructed.

All objects are constructed in exactly the same way: base classes (if any) are always constructed before data members (if any). The physical order of construction is determined by the order the base classes and its data members are declared by the class itself.

Although we cannot change how an object is constructed, we can change how it is initialised. Initialisation has no actual bearing on the construction of an object, it only affects the value of an object once it has been constructed. That is, the underlying memory layout of an object is exactly the same regardless of the object's initial value. Again, it would be a crazy world if an object's underlying memory layout could be changed simply by changing its value.

Object initialisation is achieved by invoking an appropriate constructor for the object. Even if an object specifies no constructors we can still initialise it using a member-wise initialisation list. Consider the following:

struct A {

int i;

double d;

};

A a {42, 3.14}; // member-wise initialisation: a.i=42, a.d=3.14

However, we cannot use initialisation lists to initialise base class members. This is by design because the only class that can initialise member data is the class that actually contains those members:

struct B : A {

};

B b {42, 3.14}; // Error!

The only way we can alter the initialisation of base class members is when the derived class provides an appropriate constructor and that constructor then performs the initialisation for us:

struct B : A { B (int x, double y): A {x, y} {}

};

B b {42, 3.14}; // OK! B's constructor invokes member-wise initialisation of A.

Answer 8

You can't. But you can do something similar by making the private members in the base class protected as opposed to private. This gives derived classes access to those members.

Answer 9

Public and protected data members are inherited, private data members are not. The same applies to member functions.