2010-09-05 11 views
4

J'ai ce modèle de classe où, la Banque est une classe qui va maintenant pour le réseau bancaire informatisé. Cela doit avoir ATM (Automatic Teller Machine) et aussi Cash Cashier.Utilisation de Généralisation sur l'agrégation

J'utilisé Généralisation et ont pris une classe appelée AccountHandlers héritant classe Banque. Cette AccountHandlers ont en outre ATM et HumanCashier agrégés à elle.

Maintenant, la chose est, mon ami soutenait que j'ai pris la chose de mal. Selon lui AccountHandlers doivent être agrégées à Bank et que ATM et HumanCashier doit hériter de AccountHandlers.

Je suis un peu confus sur elle. Comment puis-je le modéliser !! ou est-ce que les deux méthodes sont correctes?

Répondre

5

Je revenir aux bases.

Vous devriez vous demander si un ATMest unAccountHandler, ou si un AccountHandlera unATM. Cela devrait vous donner une réponse générale quant à l'utilisation de l'héritage ou de la composition.

deux serait correcte. Un seul serait un bon bon design et cela dépend de ce que votre application essaie de faire.

En général, il y a une règle de base (extrait de Effective Java) qui indique que vous devez privilégier la composition de l'héritage. Prenez cela avec un grain de sel, et assurez-vous que vous concevez votre application de la bonne façon. (Pour plus d'informations voir Prefer composition over inheritance?)

+0

je vous remercie pour un conseil utile. Je suis un débutant dans cette modélisation. –

1

Si cela fonctionne, c'est correct. Ne vous perdez pas dans le gaspillage de temps qu'est la modélisation UML. Écrivez un prototype et tout défaut de conception deviendra bientôt apparent.

+0

Sérieusement ?? !! Les défauts de conception ne deviennent pas toujours apparents immédiatement lorsque vous écrivez un prototype, parfois ils peuvent prendre des semaines ou des mois pour apparaître, et ils peuvent coûter beaucoup de temps à réparer. La modélisation UML n'est pas pour tout le monde, mais mieux la faille de conception devient apparente dans un diagramme que des mois plus tard dans votre code - la modélisation UML aide à s'assurer que vous l'obtenez le plus correctement possible la première fois. – slugster

+0

Absolument. C'est clairement devoirs et il y a déjà de la confusion. Si j'étais ce type, j'essaierais d'abord de le coder, de comprendre pourquoi les choses sont comme elles sont et d'en tirer le code UML. Cela l'aiderait à obtenir son futur UML dès la première fois (si cela arrive) – James

+0

Je comprends ce que vous voulez dire, mais l'essentiel est maintenant que je devrais même avoir une idée claire de comment et ce que je choisis pour ma relation dans une classe. Mais si demain il y a une situation où je suis coincé dans mon code, ce qui signifie que j'ai encore besoin de changer de design. C'est pourquoi les gens ne veulent pas perdre leur temps à changer de conception pour chaque défaut de programmation, mais créer une conception concrète et ensuite procéder. –

5

héritage général (ou spécialisation) est utilisé pour modéliser un "est-un" relation, tandis que l'agrégation/composition est utilisée pour "a-un" relations.

Maintenant, vous pouvez vous demander que l'on est correcte:

  • un gestionnaire de compte est une banque ou une banque a un ou plusieurs gestionnaires compte
  • caissier humain est un (genre spécial de) gestionnaire de compte ou gestionnaire de compte a un caissier humain

À mon avis les déclarations audacieuses sont correctes. Vous devez donc utiliser l'agrégation ou la composition pour les gestionnaires de comptes bancaires et les comptes d'héritage pour les gestionnaires de comptes.

+0

merci de donner une bonne explication –

0

Veuillez parler à vos experts du domaine et obtenez le modèle qui leur est destiné. Je pense que c'est là que les premiers chapitres de Domain Driven Design aident. Vous devriez essayer de définir les entités et leurs relations (a ou est un), les dessiner sur un tableau blanc et en discuter avec vos experts de domaine.

Malgré ce que vous faites , veuillez écrire des tests unitaires autour de votre implémentation. Parce qu'avec de telles confusions vous êtes susceptible de modifier la structure des classes et à ce moment-là vos tests unitaires vous assureront que vous pouvez facilement ré-factoriser le code.