web-dev-qa-db-fra.com

exemple de composition et d'agrégation avec diagramme de classes UML

je n'arrive pas à comprendre complètement la différence entre agrégation et composition dans un code.

Client <.> ----> BankAccount

(il est supposé être un diagramme de classe de composition Client - BankAccount).

Ainsi, dans cet exemple, le client a un compte bancaire. Cela signifie donc que lorsqu'un objet client meurt, son objet compte bancaire meurt également. Cela signifie-t-il que nous devons avoir un objet BankAccount dans la classe Client?

Class Client
{

    BankAccount acc = new BankAccount();

    public void addMoneyToBankAccount(decimal amount)
    {         
        acc.AddMoney(amount);
    }

    public decimal CheckBalance()
    {
        return acc.CheckAccountBalance();
    }

}

Alors, cette composition est-elle dans le code? À quoi ressemblerait l'agrégation dans cet exemple? Désolé pour la question du débutant, corrigez-moi si le code était erroné. Merci d'avance.

c#umlclass-diagram
15
Mefhisto1

Oui, vous appelez composition, si vous voulez vous agréger comme ceci:

Class Client
{

    BankAccount acc;

    public Client(BankAccount p_acc)
    {
      acc=p_acc;
    }

    public void addMoneyToBankAccount(decimal amount)
    {         
        acc.AddMoney(amount);
    }

    public decimal CheckBalance()
    {
        return acc.CheckAccountBalance();
    }

}

Agrégation :

Si l'héritage nous donne "est-un" et que la composition nous donne "une partie de", nous pourrions soutenir que l'agrégation nous donne une relation "a-a". Au sein de l'agrégation, la durée de vie de la pièce n'est pas gérée par le tout. Pour clarifier cela, nous avons besoin d'un exemple. Au cours des 12 derniers mois, j'ai participé à la mise en place d'un système de gestion de la relation client. Je vais donc en utiliser une partie à titre d'exemple.

Le système CRM dispose d'une base de données de clients et d'une base de données distincte qui contient toutes les adresses d'une zone géographique. L'agrégation aurait du sens dans cette situation, en tant que client a une adresse. Cela n'aurait aucun sens de dire qu'une adresse fait partie du client, car ce n'est pas le cas. Considérez-le de cette façon, si le client cesse d’exister, est-ce que l’adresse? Je dirais que cela ne cesse pas d'exister. L'agrégation est représentée sur un diagramme UML en tant que diamant non rempli.

Comme je l'ai dit au début de la réponse, voici ce que je pense de la composition et de l'agrégation. Prendre la décision d'utiliser la composition ou l'agrégation ne devrait pas être une tâche délicate. Lorsque vous modélisez des objets, vous devez simplement vous demander si cette partie fait partie ou est-ce qu’elle a un?

14
One Man Crew

Votre code client-compte bancaire est une relation composition 

Votre code satisfait toutes les propriétés de la composition

-> la durée de vie du classifieur de la pièce (BankAccount) dépend de la durée de vie du classificateur complet (Client).

-> Les données ne circulent généralement que dans un sens (c'est-à-dire du classifieur entier (Client) au classificateur de la pièce (BankAccount).

L'agrégation peut être représentée en transmettant BankAccount au client en tant qu'argument d'une méthode.

Donc, ce code est Agrégation

class client
{
    public bool updateAccount(BankAccount ba){....}
}

Comme vous pouvez le constater, il satisfait toutes les propriétés de l’agrégation.

-> il peut exister indépendamment de client

-> Les flux de données du classifieur entier (client) à la pièce (BankAccount)

7
Anirudha

Cette explication de IBM m’est utile:

Par exemple, nous pouvons considérer la voiture comme une entité entière et la roue de voiture comme une partie de la voiture. La roue peut être créée des semaines à l’avance et elle peut rester dans un entrepôt avant d’être placée sur une voiture lors de l’assemblage. Dans cet exemple, l'instance de la classe Wheel vit clairement indépendamment de l'instance de la classe Car. Cependant, il arrive que le cycle de vie de la classe de pièces ne soit pas indépendant de celui de la classe entière - c'est ce qu'on appelle l'agrégation de composition. Considérons, par exemple, la relation d’une entreprise avec ses départements. La société et les départements sont modélisés en tant que classes et un département ne peut pas exister avant une société. Ici, l'instance de la classe Department dépend de l'existence de l'instance de la classe Company.

Donc, pour moi, le cycle de vie créateur/destructeur (nouvelle version) d'une composition va à l'intérieur d'une instance; une agrégation doit avoir la possibilité d'ajouter addObject et la méthode enregistre simplement l'ID d'objet en tant qu'attribut. Ainsi, dans l'exemple ci-dessus, Client et Compte bancaire, il appartient en réalité à l'entreprise de déterminer si un compte peut exister même si l'enregistrement du client est détruit (comptes orphelins).

Class Client {
- (void) addToAccount:(BankAccount *)acc;
- (void) removeFromAccount:(BankAccount *)acc;
}

et la méthode de fermeture de compte ferait partie de l'instance d'objet BankAccount, puisqu'elle peut exister indépendamment du client.

par rapport à la méthode de composition qui oblige le client à exister, et si le client cesse d'exister, tous les comptes appartenant à ce propriétaire sont supprimés. Par conséquent, vous demanderiez à l'objet Client de vous créer un compte:

Class Client {
- (BankAccount *) openAccount;
- (BOOL) closeAccount:(BankAccount *)acc;
}
3
PapaSmurf

Oui, tu as raison. C'est un simple composition .

Pour un aggregation , votre classe Client doit conserver la référence de la classe BankAccount, mais ne doit pas contrôler sa durée de vie d'objet.

class Client
{
     private readonly BankAccount _account;

     public Client(BankAccount account)
     {
         _account = account;
     }

     //...
}

Après la destruction de l’objet Client, l’objet BankAccount utilisé peut être affecté à un autre client.

1
Dzmitry Martavoi