Agrégation et composition

Question

J'ai eu du mal à comprendre la différence entre la composition et l'agrégation en UML. Quelqu'un peut-il me proposer une bonne comparaison et un contraste entre les deux ? J'aimerais également apprendre à reconnaître la différence entre les deux dans le code et/ou voir un court exemple de logiciel/code.

Edit : Une partie de la raison pour laquelle je demande est à cause d'une activité de documentation inverse que nous faisons au travail. Nous avons écrit le code, mais nous devons revenir en arrière et créer des diagrammes de classe pour le code. Nous aimerions juste capturer les associations correctement.

Answer 1

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
}

En composition (Personne, Cœur, Main), les "sous-objets" (Cœur, Main) seront détruits dès que la Personne sera détruite.

Dans l'agrégation (Ville, Arbre, Voiture) Les "sous-objets" (Arbre, Voiture) ne seront PAS détruits lorsque la Ville sera détruite.

En résumé, la composition met l'accent sur l'existence mutuelle, et dans l'agrégation, cette propriété n'est PAS requise.

Answer 2

La distinction entre agrégation et composition dépend du contexte.

Prenons l'exemple de la voiture mentionné dans une autre réponse - oui, il est vrai qu'un échappement de voiture peut être "autonome" et ne peut donc pas être en composition avec une voiture - mais cela dépend de l'application. Si vous construisez une application qui doit effectivement traiter des échappements de voiture autonomes (une application de gestion d'atelier automobile ?), l'agrégation serait votre choix. Mais s'il s'agit d'un simple jeu de course et que le pot d'échappement ne sert qu'à faire partie d'une voiture, la composition conviendra parfaitement.

É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 en un échiquier.

Les choses se compliquent encore lorsqu'on essaie de transposer la composition/agrégation dans son langage de programmation préféré. Dans certains langages, la différence peut être plus facile à remarquer ("par référence" contre "par valeur", lorsque les choses sont simples) mais dans d'autres, elle peut ne pas exister du tout.

Et un dernier conseil ? Ne perdez pas trop de temps sur cette question. Cela n'en vaut pas la peine. La distinction n'est guère utile dans la pratique (même si vous avez une "composition" parfaitement claire, vous pouvez toujours vouloir l'implémenter comme une agrégation pour des raisons techniques - par exemple, la mise en cache).

Answer 3

La composition et l'agrégation sont des types d'associations. Elles sont très étroitement liées et, en termes de programmation, il ne semble pas y avoir une grande différence entre les deux. Je vais essayer d'expliquer la différence entre les deux à l'aide d'exemples de code java.

Agrégation : L'objet existe en dehors de l'autre, est créé en dehors, il est donc passé en argument (par exemple) au constructeur. Ex : Personnes - voiture. La voiture est créée dans un contexte différent et devient alors une propriété de la personne.

// 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, ou n'a de sens qu'à l'intérieur de l'autre, en tant que partie de l'autre. Ex : Personnes - cœur. On ne crée pas un cœur pour ensuite le transmettre à une personne. Au contraire, le cœur est créé lorsque l'humain est créé.

// 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 l'agrégation et la composition

Answer 4

La composition implique que les objets enfants partagent une durée de vie avec le parent. Ce n'est pas le cas de l'agrégation. Par exemple, un échiquier est composé de cases d'échecs - les cases d'échecs n'existent pas vraiment sans l'échiquier. Cependant, une voiture est une agrégation de pièces - un pot d'échappement est toujours un pot d'échappement même s'il ne fait pas partie d'une voiture à ce moment-là.

Answer 5

L'exemple que j'ai appris était les doigts à la main. Votre main est composée de doigts. Elle les possède. Si la main meurt, les doigts meurent. Vous ne pouvez pas "agréger" des doigts. Vous ne pouvez pas simplement aller chercher des doigts supplémentaires et les attacher et détacher de votre main à volonté.

La valeur, du point de vue de la conception, est souvent liée à la durée de vie de l'objet, comme l'a dit un autre poster. Disons que vous avez un client et qu'il possède 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 en soi et sera donc également supprimé. L'inverse est souvent vrai lors de la création d'un objet. Puisqu'un compte n'a de sens que dans le contexte d'un client, la création d'un compte devrait se faire dans le cadre de la création d'un client (ou, si vous le faites paresseusement, dans le cadre d'une transaction avec le client).

Il est utile, lors de la conception, de réfléchir aux objets qui possèdent (composent) d'autres objets par rapport à ceux qui ne font que référencer (agréger) d'autres objets. Cela peut aider à déterminer où se trouve la responsabilité de la création, du nettoyage et de la mise à jour des objets.

Dans le code, c'est souvent difficile à dire. Presque tout dans le code est une référence d'objet, il n'est donc pas toujours évident de savoir si l'objet référencé est composé (possédé) ou agrégé.