Skip to content

Inheritance. The abstract classes

Inheritance Abstract - UML

Oh good grief!
We never want to think that our employee could make a bad work, but the human error is always possible, even with the best intentions!
It's better to insure the road-map avoiding useless strengths.

The careless employee loses every responsibility, and we only must remember to add an important modifier to the method: this is abstract.

The abstract modifier has the power to make the class hosting a so declared method a class that is impossible to instantiate: every try is destined to fail.
Back to our classical example of employee, we can note that the we could impersonate the careless employee, even if we are the employer.

Indeed the latter can be viewed as an employee of himself; so we imagine a class father, the GenericEmployee, which is inherited from two classes Employer and SimpleEmployee.

You're now probably able to see that a good way to distinguish the two kinds of employees is by declaring a virtual abstract method inside the class father, so that it must be redeclared by the children.

Here we chose to distinguish an Employee as Manager and Worker.
The principle is the same.

So when we write the code relative to them about the salary, here what we could have...
in the Employee father

function CountSalary():integer; virtual; abstract;

and in the children Manager and Worker

function CountSalary():integer; override;

It's so simple but so powerful.

To summarize... when inside a class we meet a method declared as virtual and abstract we are sure that the class is abstract, that means it cannot be instantiated and that every inheriting child has to redeclare the abstract method!

Or not...?