A golden rule in coding is the modularization: the bigger your project is, the more difficult it's to keep it in a mono structure. You're naturally brought to separate logically and even in different files the code portions which are separable.
When you start to design your software in the OOP vision you surely must face these situations, in a different way: to get order inside an initial nebulous idea it's so important to recognize the who/what!
Easy to say, but only the practice and a good eyes can help you: in a big series of data your job is to assign roles and hierarchies, connections and relationships. In facts, as we said in the OOP introduction, over the who/what boxes there are the intercommunications, which are essential parts of them.
Here we show one kind, the so called composition.
Generally a composition means a concurrence of factors bound one each other, whose result is given by the factors themselves and the proportions they express: a typical example is a music composition.
In some contexts a composition defines the manner in which something is composed; not the result but the process behind.
Every meaning you find it includes the concept of relationship between two "actors", at least.
This is the point: which kind of hierarchy does the composition imply?