Storia della domanda:
Entrambi i termini — composizione e aggregazione — provengono dal design orientato agli oggetti classico. Descrivono le relazioni tra oggetti: "intero–parte", ma si differenziano per il grado di collegamento tra gli oggetti.
Problema:
Nelle grandi condizioni, la leggibilità e l'estensibilità del codice sono importanti. La composizione e l'aggregazione aiutano a costruire dipendenze corrette tra le classi. È importante comprendere la differenza — altrimenti si può rendere l'architettura troppo rigida o, al contrario, poco chiara.
Soluzione:
Composizione — è un legame forte "parte-tutto". Quando un oggetto è contenuto solo all'interno di un altro oggetto e non può esistere al di fuori di esso. In Python, tale oggetto è generalmente creato e gestito all'interno della classe "contenitore".
Aggregazione — è un legame più debole. Un oggetto "parte" può esistere separatamente dall'oggetto "tutto" e può essere passato ad esso dall'esterno.
Esempio di codice:
class Engine: def start(self): print("Motore avviato") class Car: # Composizione: Engine creato all'interno di Car def __init__(self): self.engine = Engine() def drive(self): self.engine.start() my_car = Car() my_car.drive() class Wheel: pass class Bicycle: # Aggregazione: le ruote sono passate dall'esterno def __init__(self, wheels): self.wheels = wheels w1, w2 = Wheel(), Wheel() bike = Bicycle([w1, w2])
Caratteristiche chiave:
Se si elimina l'oggetto "contenitore" (ad esempio, Car) — l'oggetto Engine verrà eliminato?
Con la composizione, se non ci sono più riferimenti all'oggetto "parte", verrà eliminato dal garbage collector. Con l'aggregazione, l'oggetto "parte" può continuare ad esistere (può essere referenziato da altri oggetti).
In Python esiste una sintassi speciale per l'aggregazione e la composizione, come in altri linguaggi?
In Python non ci sono parole chiave che indicano esplicitamente composizione/aggregazione. Dipende dal modo in cui vengono creati e gestiti il ciclo di vita degli oggetti.
È possibile cambiare la composizione in aggregazione e viceversa senza riscrivere la logica?
Non sempre. Se la logica richiede il controllo completo e l'unicità dell'oggetto "parte", una semplice sostituzione della composizione con l'aggregazione può portare a errori (ad esempio, se le ruote di diverse biciclette diventano istanze condivise di una sola classe).
Pro:
Caso negativo: In un progetto, per ogni automobile veniva creato un oggetto motore esterno e passato alla macchina tramite aggregazione. Tuttavia, poi sono state confuse le referenze agli oggetti e i motori sono stati scambiati tra macchine arbitrariamente — causando confusione e bug.
Pro: l'architettura sembrava flessibile. Contro: era difficile capire quale motore appartenesse a quale macchina.
Caso positivo: In un altro progetto, i motori venivano creati all'interno della classe Car (composizione); le automobili gestivano i propri motori direttamente, il che garantiva affidabilità.
Pro: assenza di perdite e confusione logica. Contro: è stato necessario scrivere un po' più di codice per gestire il ciclo di vita di ogni automobile e delle sue parti.