And here the code of definition inside the Employee class:
type TEmployee = class(TInterfacedObject, IHuman, ISocial)
As already seen in the previous post on interfaces, we defined a new type that is a class, which inherits from the two interfaces and the familiar TInterfacedObject.
This last is necessary for the communication between the objects of inheriting class and the inherited interfaces.
[The UML graph beside shows the hierarchy, where Employee, inherited by Worker, inherits from IHuman and ISocial]
Good: all we need to do in declaration of Employee's class is to override the methods of the two interfaces.
//ALL Interface METHODS must be redefined !!!
//Interface Human
function GetSex():string;
procedure SetSex(Sex_:string);
//Interface Social
function GetCharacter():string;
procedure SetCharacter(Character_:string);
Beautiful: and now?
Nothing has significantly changed: just we have two interfaces instead of only one.
But where's the gain?
How does this change impact on the design?
Better... why to separate the Sex and Character pseudo-attributes?
Indeed there's no good reason to do it, except for the purpose of teaching or of style exercise.
We must admit that we spent some time and strengths to find a possible second logic interface out, and that's the result: just something which can be included inside the first one.
This is because for the majority of situation a single interface does the job!
By relinking with the top of this post, the possibility of multiple inheritance is good, but in theory.
Sure this feature isn't totally redundant for use, but its usage relies on other areas of interest than the ones we're proposing.