Agrégation versus composition
J'ai eu du mal à comprendre la différence entre composition et agrégation dans UML. Quelqu'un peut-il s'il vous plaît me offrir une bonne comparaison et contraste entre eux? J'aimerais aussi apprendre à reconnaître la différence entre eux dans le code et/ou voir un court exemple de logiciel/code.
Edit: Une des raisons pour laquelle je pose cette question est due à une activité de documentation inversée que nous effectuons au travail. Nous avons écrit le code, mais nous devons revenir en arrière et créer des diagrammes de classes pour le code. Nous voudrions juste capturer les associations correctement.
La distinction entre agrégation et composition dépend du contexte.
Prenons l'exemple de voiture mentionné dans une autre réponse - oui, il est vrai qu'un échappement de voiture peut être utilisé "tout seul", de sorte qu'il n'est peut-être pas compatible avec une voiture - mais cela dépend de l'application. Si vous construisez une application qui doit réellement traiter des échappements de voiture autonomes (une application de gestion d’atelier de voiture?), L’agrégation serait votre choix. Mais s’il s’agit d’un simple jeu de course et que l’échappement de la voiture ne fait que faire partie d’une voiture, la composition serait tout à fait acceptable.
Échiquier? Même problème. Une pièce d'échecs n'existe pas sans échiquier, mais seulement dans certaines applications. Dans d’autres (comme celle d’un fabricant de jouets), une pièce d’échecs ne peut sûrement pas être composée d’un échiquier.
La situation s'aggrave encore lorsque vous essayez d'associer composition/agrégation à votre langage de programmation préféré. Dans certaines langues, la différence peut être plus facile à remarquer ("par référence" ou "par valeur", quand les choses sont simples) mais peut ne pas exister du tout.
Et un dernier mot de conseil? Ne perdez pas trop de temps sur cette question. Cela n'en vaut pas la peine. La distinction n’est guère utile en pratique (même si vous avez une "composition" parfaitement claire, vous voudrez peut-être l’implémenter comme une agrégation pour des raisons techniques - par exemple, la mise en cache).
En règle générale: 
class Person {
private Heart heart;
private List<Hand> hands;
}
class City {
private List<Tree> trees;
private List<Car> cars
}
Dans la composition (personne, cœur, main), les "sous-objets" (cœur, main) seront détruits dès que la personne sera détruite.
En agrégation (Ville, Arbre, Voiture) Les "sous-objets" (Arbre, Voiture) NE seront PAS détruits lorsque la Ville sera détruite.
Le résultat est, la composition insiste sur l'existence mutuelle, et en agrégation, cette propriété n'est pas obligatoire.
Composition et agrégation sont des types d'associations. Ils sont très liés et en termes de programmation, il ne semble pas y avoir beaucoup de différence. Je vais essayer d'expliquer la différence entre ces deux exemples avec des exemples de code Java.
Aggregation: l'objet existe en dehors de l'autre, est créé en dehors, il est donc passé sous forme d'argument (par exemple) au constructeur. Ex: People - voiture. La voiture est créée dans un contexte différent et devient ensuite une propriété individuelle.
// code example for Aggregation:
// reference existing HttpListener and RequestProcessor
public class WebServer {
private HttpListener listener;
private RequestProcessor processor;
public WebServer(HttpListener listener, RequestProcessor processor) {
this.listener = listener;
this.processor = processor;
}
}
Composition: l'objet n'existe que, ou n'a de sens que dans l'autre, en tant que partie de l'autre. Ex: Les gens - le coeur. Vous ne créez pas un cœur et le transmettez ensuite à une personne.
// code example for composition:
// create own HttpListener and RequestProcessor
public class WebServer {
private HttpListener listener;
private RequestProcessor processor;
public WebServer() {
this.listener = new HttpListener(80);
this.processor = new RequestProcessor(“/www/root”);
}
}
Expliqué ici avec un exemple Différence entre agrégation et composition
La composition implique que les objets enfants partagent une durée de vie avec le parent. L'agrégation ne fonctionne pas. Par exemple, un échiquier est composé de carrés d'échecs - les carrés d'échecs n'existent pas vraiment sans le plateau. Cependant, une voiture est un ensemble de pièces: un échappement de voiture est toujours un échappement de voiture s'il ne fait pas partie d'une voiture à ce moment-là.
L'exemple que j'ai appris était les doigts à la main. Votre main est composée de doigts. Il les possède. Si la main meurt, les doigts meurent. Vous ne pouvez pas "agréger" les doigts. Vous ne pouvez pas simplement attraper des doigts supplémentaires et les attacher et les détacher de votre main à volonté.
La valeur ici, du point de vue de la conception, est souvent liée à la durée de vie d'un objet, comme l'a dit une autre affiche. Supposons que vous avez un client et qu'ils ont un compte. Ce compte est un objet "composé" du client (du moins, dans la plupart des contextes auxquels je peux penser). Si vous supprimez le client, le compte n'a aucune valeur, il sera donc également supprimé. L'inverse est souvent vrai lors de la création d'un objet. Dans la mesure où un compte n'a de sens que dans le contexte d'un client, la création de compte doit s'inscrire dans le cadre de la création du client (ou, si vous le faites paresseusement, cela fait partie d'une transaction client).
Dans la conception, il est utile de déterminer quels objets possèdent (composent) d'autres objets par rapport à ceux qui référencent simplement (agrégent) d'autres objets. Cela peut aider à déterminer où se trouve la responsabilité de la création, du nettoyage et des mises à jour des objets.
En ce qui concerne le code, c'est souvent difficile à dire. La plupart des éléments du code sont des références d'objet. Par conséquent, il peut ne pas être évident que l'objet référencé soit composé (détenu) ou agrégé.
En termes de code, composition suggère généralement que l'objet contenant est responsable de la création d'instances du composant *, et que l'objet contenant contient les seules références de longue durée à ce dernier. Ainsi, si l'objet parent est dé-référencé et récupéré, l'enfant le sera également.
alors ce code ...
Class Order
private Collection<LineItem> items;
...
void addOrderLine(Item sku, int quantity){
items.add(new LineItem(sku, quantity));
}
}
suggère que LineItem est un composant de Order - LineItems n’existe pas en dehors de leur ordre contenant. Mais les objets Item ne sont pas construits dans l'ordre, ils sont transmis selon les besoins et continuent d'exister, même si le magasin n'a pas de commande. donc ils sont associés, plutôt que des composants.
* n.b. le conteneur est responsable pour l'instanciation du composant, mais il pourrait ne pas être appelé nouveau ... () lui-même - ceci étant Java, il y a généralement une usine ou deux à passer en premier!
Il est si difficile de faire la différence entre une relation globale et une relation composite, mais je vais prendre quelques exemples, .__ Nous avons une maison et des chambres, ici nous avons une relation composite, une pièce qui fait partie de la maison, et la vie dans la chambre a commencé avec la vie dans la maison et se terminera lorsque la vie dans la maison sera terminée, la chambre fait partie de la maison, nous parlons de composition, comme pays et capitale, livre et pages . peut exister sans équipe, et l'équipe est un groupe de joueurs, et la vie du joueur peut commencer avant la vie de l'équipe, si nous parlons de programmation, nous pouvons créer des joueurs et après nous créerons une équipe, mais pour la composition non, nous créons des salles à l'intérieur de house . Composition ----> composite | composer . Agrégation -------> groupe | élément
Fixons les termes. L'agrégation est un métaterm de la norme UML et signifie à la fois la composition et l'agrégation partagée, simplement nommées shared. Trop souvent, il est mal nommé "agrégation". C'est mauvais, car la composition est aussi une agrégation. Si je comprends bien, vous voulez dire "partagé".
Plus loin du standard UML:
composite - Indique que la propriété est agrégée de manière composite, c’est-à-dire que l’objet composite est responsable de l’existence et stockage des objets composés (pièces).
Ainsi, l'association Université à cathédrales est une composition, car cathedra n'existe pas hors Université (IMHO)
La sémantique précise de l'agrégation partagée varie selon le domaine d'application et modeleur.
En d'autres termes, toutes les autres associations peuvent être dessinées en tant qu'agrégations partagées, si vous ne suivez que certains de vos principes ou de ceux de quelqu'un d'autre. Regardez aussi ici .
L’exemple que j’aime: Composition: L’eau est un partie-de un étang. (L'étang est une composition d'eau.) Agrégation: Étang a canards et poissons
Comme vous pouvez le voir, j'ai mis en gras "part-of" et "has", car ces 2 phrases peuvent généralement indiquer quel type de connexion existe entre les classes.
Mais comme l'ont souligné d'autres personnes, le fait que la connexion soit une composition ou une agrégation dépend souvent de l'application.
Les illustrations conceptuelles fournies dans d'autres réponses sont utiles, mais j'aimerais partager un autre point que j'ai trouvé utile.
Je profite de l'expérience UML pour la génération de code, pour le code source ou DDL pour les bases de données relationnelles. Là, j'ai utilisé composition pour indiquer qu'une table a une clé étrangère non nullable (dans la base de données) et un objet "parent" (et souvent "final") non nullable dans mon code. J'utilise l'agrégation lorsque je souhaite qu'un enregistrement ou un objet puisse exister en tant qu '"orphelin", ne soit attaché à aucun objet parent, ou soit "adopté" par un autre objet parent.
En d'autres termes, j'ai utilisé la notation de composition comme un raccourci pour impliquer des contraintes supplémentaires qui pourraient être nécessaires lors de l'écriture de code pour le modèle.
Considérons des parties du corps humain comme les reins, le foie, le cerveau ... Si nous essayons de cartographier le concept de composition et d'agrégation ici, ce serait comme:
Avant l'avènement des greffes de parties du corps comme celles des reins et du foie, ces deux parties du corps étaient en composition avec le corps humain et ne pouvaient exister d'isolement avec le corps humain.
Mais après l'avènement de la transplantation de parties du corps, elles peuvent être transplantées dans un autre corps humain. Ces parties sont donc en agrégation avec le corps humain, leur existence en isolation avec le corps humain étant désormais possible.