When you face the matter of writing duplicated code, an idea generally rises about how to not waste time.
In strongly typed coding languages a simple mechanism exists, aiding the coder to solve the problem.
The so called Template.
They are designed so that classes and functions able to work with generic types, giving them the possibility to operate on different data types without the need of rewriting code for each of them.
Maybe you've just thought about the concept key: the abstraction.
Indeed we're dealing with it in the sense described above: a template is a try to avoid useless repeating code writing, and to do this we're forced to find a more general way than the direct and boring one.
From the article we highlighted their total abstraction.
We noticed that it's contained methods must be overridden by the inherited class(es).
Furthermore a interface does not have any attributes.
Finally we wrote - just on the rush - that the Interfaces mechanism overpasses one compiler's weak point, about the inability to support the multiple inheritance.
In brief: the multiple inheritance in FreePascal grants that an inheriting class can inherits from more than one more abstract class.
It so expands its possibility to enrich itself, always by keeping the order and the hierarchy achieved with the interfaces.
We've finished the previous article on inheritance talking about the way used in FreePascal (and in Delphi too) to make a class abstract; we've learned that by declaring just one method as virtual abstract is enough to get the result.
But again we've seen that is not true, indeed.
Theory says one thing, and reality another one! This is a rule you should always keep in mind, because reality always doesn't care of your thoughts. 😉
Back to our example... is there a way to get a true abstract class? Luckily yes!
Third and last step on the inheritance: here to describe a situation where this mechanism is required, or better forced, to be adopted, in case we need to create object from a class.
What precisely does it mean?
We always have designed and realized classes with the clear intention to be used as direct prototypes for instantiation of objects.
And that's right; but if you remember we, by talking about inheritance in the two last articles, mentioned that when a method in a class is declared as virtual, it means that every child of the class can override that method, but never it will be forced to do.
Let's face the other side of the medal: how to make necessary a redeclaration by every child of a particular class?
But before the practice, what is the idea guiding us?
Try to think of a general class, so general that it cannot be directly turned into reality: no need to concentrate on informatics applications, the physical reality of every day can help us.
By approaching with the concept and mechanism of inheritance it is possible to notice how it guides us from more generic classes into specialized ones, based on the project's specifics.
Inheritance is potentially infinite; only our needs (and computer's memory) can put a stop to the chain of children.
In any case what we learned is that the public and private attributes are inherited as they are: respectively public and private.
[But while the former are accessible, the latter aren't!]
The other aspect we talked about relates to necessity of specializing the new classes with new attributes and/or methods: a special setting wants a method to be shared among the father and the children classes, so that it can be declared virtual in the first.
It's required when a method, enough for the father which is initially designed for, becomes a base for the children where to be redeclared.
In the last article we saw the printing method, for the employees and the workers: a two-levels hierarchy, the simplest case of inheritance.
And if you remember (but you read it first? :)) we avoided to add a button, onto the form, bound to the redeclared method in the Worker class, because it would have been redundant; in facts it would have been same as using the direct Worker's printing method.