And that's what is represented in the UML class diagram in the picture beside.
This relationship is called aggregation.
As the name says we have two (independent) classes which are aggregated: here the Employee and the Hat.
We now explain its features.
In a certain manner a hierarchy still subsists: while a hat can exist by itself, it can belong only to one employee; on the other side an employee can have more than one hat.
Now notice the symbol used to express the aggregation: an empty rhombus which goes from the Employee and arrives to Hat with an arrow.
And the number ratio is one-to-many: 1 and * respectively.
Now let us add an important note: in the previous article on composition we talked about the ratio, and we saw the an employee can have a document at least.
To be more precise, he must have a document at least: that's why the employee's creation required the contextual creation of a document.
And in that case the notation was: 1 and 1..* .
But here is different: on Hat side we have only an asterisk *, which means that an employee really can have one hat at least, but without any obligation; even zero!
And this doesn't affect the existence of a possible hat.
In our code we have three classes: the usual main (with the form), the familiar Employee and the new Hat.
Well... the first two can access one each other because of the reciprocal uses inclusion.
The Employee object mustn't have a hat, thus it doesn't use its class; neither this uses the other first two (obviously).
So... who creates the hats?
The main class file includes the Hat one with the uses command: this gives us the possibility to manage all its public members, like the constructor, by binding them to visual objects events.
Both Employee and Hat are in the scope of the main.
In facts the GUI shows two sections where the objects can be created independently, and another where to make the association here described as aggregation.
But once a hat is created, who takes care of it?
The employee object: this explain the choice to create a list of hat inside the Employee's constructor.
Even if you write classes all aggregated, you must provide a mechanism of instantiation: this means that a (subtle) hierarchy always exists.
[As already said FreePascal is hierarchic by nature, with the TObject class implicitly used as reference]