Abbiamo detto che una delle attività fondamentali in un progetto creato con linguaggi di programmazione orientati ad oggetti è stabilire i rapporti tra le classi. 
Nella programmazione ad oggetti, due modi di mettere in relazione le classi sono l’ereditarietà (che abbiamo affrontato precedentemente) e l’Object Composition, che analizzeremo in questo articolo.

Come abbiamo potuto capire, la relazione di ereditarietà rende difficile cambiare la classe padre, in quanto queste modifiche andrebbero a ripercuotersi su tutte le classi figlie che, quindi, andrebbero riadattate.

In tal senso, invece, la composizione prevede un approccio che rende assai più semplice modificare il codice.

Inoltre, al contrario dell’ereditarietà, la composizione è più dinamica, in quanto ogni oggetto può essere rimpiazzato da un altro oggetto purchè, però, sia dello stesso tipo. 
Non di meno, evita anche la costruzione di gerarchiche classi enormi e quindi poco gestibili.

Di contro, l’Object Composition è, però, più complessa dell’ereditarietà, in quanto porta a un aumento del numero degli oggetti istanziati.

Confuso? Non temere. Andiamo a tradurre quanto detto in codice, riutilizzando il nostro caro esempio precedente del computer.

Creazione di un oggetto tramite Composition

Nell’esempio del capitolo precedente, parlando della Dependency Injection, abbiamo dichiarato come la classe Computer utilizzasse la classe MotherBoard per funzionare.
Essendo MotherBoard un concetto molto ampio (diversi formati, diversi tipi di socket CPU, diversi tipi di RAM supportate ecc.), possiamo pensare di trasformare MotherBoard in una classe astratta.

abstract class MotherBoard{
  public $format;
  public $socket;
  public $ram;
}

Andiamo, poi, a creare delle classi che estendono la classe astratta, ognuna per ogni tipo di scheda madre.

class MsiB550 extends MotherBoard{
  public function __construct($format, $socket, $ram){
    $this->format = 'ATX';
    $this->socket = 'AM4';
    $this->ram = 'DDR4';
  }
}

  class MsiCreator extends MotherBoard{
    public function __construct($format, $socket, $ram){
    $this->format = 'E-ATX';
    $this->socket = 'TRX4';
    $this->ram = 'DDR4';
  }
}

Adesso, possiamo tornare al nostro Computer, come lo avevamo lasciato nel precedente capitolo.

class Computer {
  public $motherBoard;
  public function __construct(MotherBoard $motherBoard){
    $this->motherBoard = $motherBoard;
  }
}

Grazie alla Object Composition noi possiamo comporre, appunto, un’istanza di classe Computer come vogliamo: infatti, le classi MsiB550 e MsiCreator, estendendo la classe astratta MotherBoard, ne condividono il tipo (o interfaccia).
Questo si traduce nella possibilità di richiamare la funzione costruttore, continuando a rispettare il type hinting della Dependency Injection.

$computer1 = new Computer(new MsiB550());
$computer2 = new Computer(new MsiCreator());

echo $computer1->motherBoard->format . "\n";
echo $computer2->motherBoard->format;

//Output:
// ATX
// E-ATX

Questo tipo di gestione ci ha permesso di creare due istanze di classe Computer completamente diverse tra loro e che potenzialmente possono comportarsi in maniera totalmente differente. Non male, eh?

Ereditarietà VS Object Composition: quale utilizzare?

Come spesso accade nel mondo della programmazione informatica, uno sviluppatore web può, non di rado, trovarsi davanti ad un bivio. Giunto a questo punto delle nostre lezioni php avrai assimilato le differenze tra Ereditarietà e Object Composition.
Ma quale scegliere, tra le due?
Non sentirsi spaesato! Dal punto di vista prettamente didattico, dovremmo scegliere tra ereditarietà e composizione in base alla relazione che vogliamo esprimere:

• l’ereditarietà è da preferire quando un oggetto di una classe figlia è anche un oggetto della classe padre: per esempio, Person -> Teacher. Questo tipo di relazione viene chiamata is-a; In generale usiamo l ereditarietà quando la classe che stiamo creando specializza la classe padre.
• la composizione, invece, è da preferire quando un’istanza di una classe ha, al suo interno, un’istanza di un’altra classe, senza alcun tipo di legame ereditario: per esempio, Computer -> MotherBoard. Questo tipo di relazione viene definito has-a.

Nb. si può trasferire questo ragionamento anche ai metodi:

• se tutti i metodi di una classe devono essere anche di un’altra, allora si usa l’ereditarietà;
• se alcuni metodi di una classe non devono essere metodi anche di un’altra, allora si usa l’Object Composition.