Here beside the UML class diagram shows the hierarchy described before.
As you can see the last arrow points from WorkerPartTime to Worker, so the former inherits (uses) the latter.
And obviously Worker inherits Employee.
Again: WorkerPartTime gains the Worker's features, which contains the Employee's ones.
At this point you could ask yourself if a child class could access a private attributes of its ancestors and access them too.
We indeed saw that every public attribute is inheritable and accessible by the children; clearly this is a good reason to write a virtual method in public section.
But it's the main reason, or only a good one?
In other words, are we forced to do so?
Simply yes (until now)!
First of all, remember that every OOP principle must be respected and followed: in this case we're playing with the encapsulation (information hiding), which grants us that... private attributes are accessible only by the class itself where they're declared.
Does it mean that private members aren't inherited?
Surely they are, and we have the answer by the encapsulation rules.
The children classes will inherit everything from the father, but they won't access its private attributes.
Good, indeed; but what if we wanted to have a mixed opportunity? special private members which could be inherited?
Every OOP language (we suppose) offers a class access modifier who solves this problem: this is the protected.
It's nature is a fusion of private and public.
Inside the class where a protected member is declared, its behavior is completely similar to a private one.
But when a class inherits, the inherited protected one becomes accessible as it was public, but not completely.
In facts a public attribute is accessible from any item which could see it (scope ok!), while a protected one is accessible only by (the class itself and) the children!
[That's what we have done in this example, about the WorkerPartTime class; in the previous page, the code reports the NumberOfWorkingDays integer, and protected]
This can be difficult to get from our usual examples, because of the separation of every file for every class.
Just think to write two classes in the same file: their public attributes will be both accessible by one to each other.
Beside the present main argument, if we write two classes in the same file, but we wanted to inherit the second from the first?
type
TPoint = class
...
end;
TLine = class(TPoint)
private
lineLenght : Byte;
...
end;
Back to our code, if you're not sure of our words, test it yourself.
Inside any function of WorkerPartTime try to write a private Worker's attribute (if present) and compile: the compiler will warn you about its nonexistence.
Correctly it's just a matter of inaccessibility!
[It will be enough to start typing the name, and then try to complete with Control+Space: if the suggestion frame will open, it won't contain the voice you'll look for]