By discovering the beauty of OOP world, in the essential view here offered, we always have underlined how the classes are designed as objects prototypes which implicitly include the possibility to communicate among them, with precise mechanisms.
For the sake of precision, some classes can be written only as general model, without the goal to be transposed in reality as objects.
While this is true, for now let's concentrate only on the fact that a class implies an instantiation, at least.
So the class design at this level requires the knowledge of the relations that its objects must set.
Previous time we saw the composition, between the two involved classes Employee and Document.
To summarize: while an employee object can exist by itself and can have one or more documents, the document object cannot exist by itself and can only belong to an employee.
In UML representation we had a black fulfilled rhombus starting from the class Employee and ending into the class Document with an arrow, with these extreme points denoted by the correct ratio numbers.
This relationship shows clearly a hierarchy!
But what could happen if the classes can exist independently (especially one from the other)?
The prospective changes and consequently we are forced to adopt another management.
Nothing complicated indeed; simply we must remember the classes are on the same level now.
But how to translate this in code?
Here our example.
An employee exists, because an office hires him, but on the other hand this office exists because of employees existence.
More or less we can say that not only they are on the same level of existence, but that they are interdependent.
There is another possibility: the classes are on the same existence level, and they don't depend one from the other.