Apparentemente, un modello di design composito rappresenta le singole entità e le entità collettive nello stesso modo.
Qual è il vantaggio di questo? Ad esempio, se sottoclassi una classe, perché dovrei trattare gli oggetti di entrambe le classi nello stesso modo?
Ad esempio, se "tonno" è una sottoclasse di "pesce", perché dovrei avere le stesse implementazioni per i metodi degli oggetti in entrambe le classi?
La relazione descritta in schemi di progettazione compositi non è una relazione di sottoclasse, è una relazione di raccolta. In altre parole, si tratta di trattare un tonno uguale a una scuola di tonno. In questo modo per operazioni come la traslazione, la rotazione, il ridimensionamento, il disegno, ecc., Il chiamante non deve preoccuparsi se agisce su un oggetto o un'intera collezione.
Non applichi Composito per trattare Tonno e Pesce allo stesso modo. Per farlo, devi semplicemente usare Pesce, perché ogni Tonno è Pesce.
Il composito è utile quando più elementi espongono la stessa interfaccia di ognuno di essi separata. Ma c'è il colpo. L'elemento composito è quindi responsabile di iterare attraverso la raccolta (come in questo articolo: Working With Collections ) e per aggregare più risultati in un unico risultato (come in questo articolo: Composite Design Pattern ).
In realtà, Composite applica il principio di responsabilità singola in quanto separa il passaggio di aggregazione dalla funzione effettiva, che viene quindi inclusa nell'elemento semplice.
Leggi altre domande sui tag design-patterns