Histoire de la question :
Les deux termes — composition et agrégation — proviennent de la conception orientée objet classique. Ils décrivent les relations entre objets : "tout-partie", mais se distinguent par le degré de liaison entre les objets.
Problème :
Dans les grands systèmes, la lisibilité et l'extensibilité du code sont importantes. La composition et l'agrégation aident à établir des dépendances appropriées entre les classes. Il est important de comprendre la différence — sinon, on peut rendre l'architecture trop rigide ou, au contraire, floue.
Solution :
Composition — c'est un lien fort « partie-tout ». Lorsqu'un objet est contenu uniquement à l'intérieur d'un autre objet et ne peut pas exister en dehors de celui-ci. En Python, cet objet est généralement créé et géré à l'intérieur de la classe "conteneur".
Agrégation — c'est un lien plus faible. L'objet "partie" peut exister séparément de l'objet "tout" et être transmis à celui-ci de l'extérieur.
Exemple de code :
class Engine: def start(self): print("Moteur démarré") class Car: # Composition : Engine créé à l'intérieur de Car def __init__(self): self.engine = Engine() def drive(self): self.engine.start() my_car = Car() my_car.drive() class Wheel: pass class Bicycle: # Agrégation : les roues sont transmises de l'extérieur def __init__(self, wheels): self.wheels = wheels w1, w2 = Wheel(), Wheel() bike = Bicycle([w1, w2])
Caractéristiques clés :
Si l'objet "conteneur" (par exemple, Car) est supprimé, l'objet Engine sera-t-il supprimé ?
Avec la composition, si aucun autre objet ne fait référence à l'objet "partie", il sera supprimé par le ramasse-miettes. En revanche, avec l'agrégation, l'objet "partie" peut continuer à exister (il peut encore être référencé par d'autres objets).
Python a-t-il une syntaxe spéciale pour l'agrégation et la composition, comme dans d'autres langages ?
En Python, il n'y a pas de mots-clés indiquant explicitement la composition/agrégation. Tout dépend de la façon dont les objets sont créés et de leur cycle de vie.
Peut-on remplacer la composition par l'agrégation et vice versa sans réécrire la logique ?
Pas toujours. Si la logique nécessite un contrôle total et l'unicité de l'objet "partie", un simple remplacement de la composition par l'agrégation peut entraîner des erreurs (par exemple, si les roues de différents vélos deviennent des instances communes de la même classe).
Avantages :
Cas négatif : Dans un projet, un objet moteur externe était créé pour chaque voiture et était transmis à la voiture par agrégation. Cependant, après, les références aux objets ont été mélangées et les moteurs ont été échangés entre les voitures au hasard — ce qui a entraîné de la confusion et des bugs.
Avantages : l'architecture semblait flexible. Inconvénients : il était difficile de comprendre quel moteur appartenait à quelle voiture.
Cas positif : Dans un autre projet, les moteurs étaient créés à l'intérieur de la classe Car (composition) ; les voitures géraient directement leurs moteurs, ce qui assurait la fiabilité.
Avantages : pas de fuites et de confusion logique. Inconvénients : il a fallu écrire un peu plus de code pour gérer le cycle de vie de chaque voiture et de ses pièces.