L'agrégation rapport à la Composition [fermé]

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 est détruite.

l'agrégation (Ville, un Arbre, une Voiture) "sous-objets" (Arbre, Voiture) ne sera PAS détruite lors de la Ville est détruite.

la ligne de fond est, la composition des contraintes sur les mutuelles existence, et de l'agrégation, cette propriété n'est PAS nécessaire.

implique que les objets enfant partagent une durée de vie avec le parent. L'agrégation ne l'est pas. Par exemple, un échiquier est composé de carrés d'échecs - les carrés d'Échecs n'existent pas vraiment sans l'échiquier. Toutefois, une voiture est une agrégation de parties d'une voiture d'échappement est encore un échappement de voiture si ce n'est pas une voiture à la fois.

Composition et agrégation sont des types d'associations. Ils sont très étroitement liés et en termes de programmation, il ne semble pas beaucoup de différence. Je vais essayer d'expliquer la différence entre ces deux exemples de code java

agrégation : l'objet existe en dehors de l'autre, il est créé en dehors, il est donc transmis comme argument (par exemple) à l'interprète. Ex: Personnes – voiture. La voiture est créé dans un contexte différent et devient alors une personne bien.

// 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 que dans l'autre, comme une partie de l'autre. Ex: les Gens de coeur. On ne crée pas un cœur et on le transmet à 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

l'exemple que j'ai appris était doigts à la main. Votre main est composée de doigts. Il possède. Si la main meurt, les doigts meurent. On ne peut pas "agréger" les doigts. Vous ne pouvez pas simplement aller prendre des doigts et d'attacher et de détacher de votre main.

la valeur ici, du point de vue de la conception, est souvent liée à la durée de vie de l'objet, comme le dit une autre affiche. Dites que vous avez un client et qu'ils ont un compte. Ce compte est un objet "composé" du client (au moins, dans la plupart des contextes, que je pense). Si vous supprimez le Client, le Compte n'a pas de valeur en soi de sorte qu'il serait supprimé. L'inverse est souvent vrai pour la création d'objets. Étant donné qu'un compte n'a de sens que dans le contexte D'un client, la création d'un compte doit se faire dans le cadre de la création D'un client (ou, si vous le faites par paresse, dans le cadre d'une transaction avec un client).

il est utile dans la conception de penser à ce que les objets possèdent (composer) d'autres objets par rapport à ceux Cela fait simplement référence à d'autres objets (agrégés). Il peut aider à déterminer où se situe la responsabilité de la création, du nettoyage et de la mise à jour des objets.

d'après le code, c'est souvent difficile à dire. La plupart de tout dans le code est une référence d'objet donc il ne peut pas être évident si l'objet référencé est composé (possédé) ou agrégé.

il est étonnant de constater à quel point il y a confusion au sujet de la distinction entre les partie-entier - association concepts agrégation et composition . Le principal problème est l'incompréhension généralisée (même parmi les développeurs de logiciels experts et parmi les auteurs D'UML) que le concept de composition implique une dépendance du cycle de vie entre l'ensemble et ses parties de telle sorte que les parties ne peuvent pas exister sans l'ensemble. Mais ce point de vue ne tient pas compte du fait qu'il existe également des cas d'association partielle-totale avec des parties non partageables où les parties peuvent être détachées du tout et survivre à sa destruction.

dans le document de spécification UML, la définition du terme "composition" a toujours impliqué des parties non partageables, mais il n'a pas été clair ce qui est la définition caractéristique de la "composition", et ce qui n'est qu'une caractéristique facultative. Même dans la nouvelle version (à partir de 2015), UML 2.5, après une tentative d'améliorer la définition du terme "composition", il reste encore ambigu et ne fournit aucune orientation sur la façon de modéliser des associations de parties entières avec des parties non partageables où les parties peuvent être détachées de, et survivre à la destruction de, l'ensemble par opposition au cas où les parties ne peuvent pas être détachées et sont détruits avec le ensemble. Ils disent

si un objet composite est supprimé, toutes les instances de ses parties qui sont des objets sont supprimées avec lui.

Mais en même temps, ils disent aussi

une pièce peut être enlevée d'un objet composite avant que l'objet composite ne soit supprimé, et donc ne pas être supprimée en tant que partie de l'objet composite.

cette confusion pointe à une définition incomplète de L'UML, qui ne tient pas compte de la dépendance du cycle de vie entre les composants et les composites. Il est donc important de comprendre comment la définition UML peut être améliorée en introduisant un stéréotype UML pour les compositions << inséparables >> où les composants ne peuvent pas être détachés de leur composite, et, par conséquent, doivent être détruits chaque fois que leur composite est détruit.

1) Composition

comme Martin Fowler a expliqué , la question principale pour caractériser la composition est que"un objet ne peut être que la partie d'un rapport de composition". Cela est également expliqué dans l'excellent blog post UML Composition vs agrégation vs Association par Geert Bellekens. En plus de cette caractéristique de définition d'une composition (d'avoir exclusif , ou non partageable , parties), une composition peut également venir avec une dépendance du cycle de vie entre le composite et ses composants. En fait, il existe deux types de telles dépendances:

1. chaque fois qu'un composant doit toujours être fixé à un composite, ou, en d'autres termes, lorsqu'il a un composite obligatoire , exprimée par la multiplicité" exactement une " Du côté composite de la ligne de composition, alors elle doit soit être réutilisée (ou rattachée) à un autre composite, soit être détruite lorsque son composite actuel est détruit. Cela est illustré par la composition entre Person et Heart , illustrée dans le schéma ci-dessous. Un cœur est soit détruit ou transplanté à une autre personne, lorsque son propriétaire est décédé.
2. chaque fois qu'un composant ne peut pas être détaché de son composite, ou, en d'autres termes, quand il est inséparable , alors, et seulement alors, le composant doit être détruit, quand son composite est détruit. Un exemple d'une telle composition avec des parties inséparables est la composition entre Person et Brain .

en résumé, les dépendances du cycle de vie ne s'appliquent qu'aux cas spécifiques de composition, mais pas en général, elles ne sont donc pas une caractéristique déterminante.

la spécification UML stipule:" une partie peut être retirée d'une instance composite avant que l'instance composite ne soit supprimée, et donc ne pas être supprimée en tant que partie de l'instance composite."Dans l'exemple d'une composition Car - Engine , comme le montre le schéma suivant, il est clair que le moteur peut être détaché de la voiture avant de la voiture est détruite, dans lequel cas, le moteur n'est pas détruit et peut être ré-utilisé. C'est ce qu'implique la multiplicité zéro ou un du côté composite de la ligne de composition.

le multiplicité de l'extrémité d'association d'une composition du côté composite est soit 1 soit 0..1, selon le fait si les composants ont un composite obligatoire (doit être fixé à un composite) ou non. Si les composants sont inséparable , cela implique qu'ils ont un composite obligatoire.

2) agrégation

Une agrégation est une autre forme particulière d'association avec la signification d'un ensemble de relations, où les parties d'un ensemble peuvent être partagés avec d'autres ensembles. Par exemple, nous pouvons modéliser une agrégation entre les classes DegreeProgram et Course , comme le montre le diagramme ci-dessous, étant donné qu'un cours fait partie d'un programme menant à un diplôme et qu'un cours peut être partagé entre deux ou plusieurs programmes menant à un diplôme (par exemple, un diplôme d'ingénieur peut partager un cours de programmation C avec un diplôme d'informatique).

cependant, le concept d'agrégation avec pièces partageables ne signifie pas beaucoup, vraiment, donc il n'a pas d'implications sur la mise en œuvre et de nombreux développeurs préfèrent donc ne pas utiliser le diamant blanc dans leurs diagrammes de classe, mais simplement modéliser une association simple à la place. La spécification UML dit:"la sémantique précise de l'agrégation partagée varie selon le domaine d'application et le modélisateur".

le multiplicité de l'association d'une agrégation se termine sur le côté entier peut être n'importe quel nombre (*) parce qu'une partie peut font partie de, ou partagé parmi, n'importe quel nombre de wholes.

en termes de code, la composition suggère habituellement que l'objet contenant est responsable de la création des instances du composant*, et l'objet contenant détient les seules références à long terme à celui-ci. Donc, si l'objet parent est dé-référencé et que les ordures sont ramassées, l'enfant le sera aussi.

donc 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 une composante d'ordre - LineItems n'ont aucune existence en dehors de leur ordre contenant. Mais les objets ne sont pas construits dans l'ordre - ils sont passés en tant que de besoin, et continuent à exister, même si le magasin n'a pas de commandes. donc ils sont associés, plutôt que des composants.

* N. B. le conteneur est responsable pour instanciating le composant, mais il pourrait ne pas appeler en fait nouveau...() lui - même-cela étant java, il ya habituellement une usine ou deux à passer en premier!

les illustrations conceptuelles fournies dans d'autres réponses sont utiles, mais j'aimerais partager un autre point que j'ai trouvé utile.

J'ai obtenu un certain kilométrage de UML pour la génération de code, pour le code source ou DDL pour la base de données relationnelle. Là, j'ai utilisé la composition pour indiquer qu'une table a une clé étrangère non-nullable (dans la base de données), et un objet "parent" non-NULL (et souvent "final"), dans mon code. J'utilise agrégation où j'ai l'intention d'un enregistrement ou d'un objet à être en mesure d'exister comme un "orphelin", n'est lié à aucun objet parent, ou d'être "adopté" par un autre parent de l'objet.

en d'autres termes, j'ai utilisé la notation de composition comme un raccourci pour suggérer quelques contraintes supplémentaires qui pourraient être nécessaires lors de l'écriture de code pour le modèle.

L'exemple que j'aime: Composition: L'eau est un partie-de un Étang. (L'étang est une composition de l'eau.) agrégation: contient canards et poissons (agrégats d'étangs, canards et poissons)

comme vous pouvez le voir, j'ai en caractères gras" part-of "Et" has", car ces deux phrases peuvent typiquement indiquer quel type de lien existe entre les classes.

mais comme souligné par d'autres, plusieurs fois si la connexion est une composition ou une agrégation dépend de l'application.

il est si difficile de faire une différence entre la relation agrégée et la relation composite, mais je vais prendre quelques exemples, Nous avons une maison et des chambres, ici nous avons une relation composite, chambre c'est une partie de la maison , et la vie de la chambre a commencé avec la vie de la maison et se terminera quand la vie de la maison est terminée, chambre c'est une partie de la maison, nous parlons de la composition, comme le pays et le capital, livre et pages. Pour la relation agrégée exemple, prenez l'équipe et les joueurs, le Joueur peut exister sans l'équipe, et l'équipe est un groupe de joueurs, et la vie de joueur peut commencer avant la vie d'équipe, si nous parlons de programmation, nous pouvons créer des joueurs et après nous allons créer l'équipe, mais pour la composition non, nous créons des salles à l'intérieur de la maison . Composition ----> composite|composant. L'agrégation -------> groupe | élément

fixons les conditions. L'agrégation est un métaterme dans la norme UML, et signifie à la fois la composition et l'agrégation partagée, simplement appelé partagé . Souvent il est nommé incorrectement "agrégation". C'est mauvais, car la composition est aussi une agrégation. Si je comprends bien, vous voulez dire "partagé".

plus loin de la norme UML:

composite-indique que la propriété est agrégée de façon composite, c'est à dire, le l'objet composite a la responsabilité de l'existence et stockage des objets composés (pièces).

ainsi, L'association Université-cathedras est une composition, parce que la cathedra n'existe pas hors de L'Université (IMHO)

la sémantique précise de l'agrégation partagée varie selon le domaine d'application et le type d'agrégation. modeleur.

c'est-à-dire, toutes les autres associations peuvent être tirées comme agrégations partagées, si vous êtes seulement en suivant certains de vos principes ou de quelqu'un d'autre. Regardez aussi ici .

considérez les parties du corps humain comme le rein, 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 de la transplantation de parties du corps comme celles du rein et du foie, ces deux parties du corps étaient en composition avec le corps humain et ne peuvent exister en isolation avec le corps humain.

mais après l'avènement de la transplantation de parties du corps, ils peuvent être transplantés dans un autre corps humain, de sorte que ces les parties sont en agrégation avec le corps humain car leur existence dans l'isolement avec le corps humain est maintenant possible.