POO : référencer un objet dans un autre objet

Salut :)


Je développe une application de gestion de comptes bancaires - pour mon usage et mon plaisir.
Pour l'instant j'ai développé surtout en procédural. Je cherche à migrer vers un développement Objet - pour apprendre.

J'ai plusieurs tables, notamment :
- Table des Comptes bancaires => classe Compte
- Table des Opérations bancaires => classe Operation
- Table des Moyens de paiement => classe MoyenPaiement
- Table des Postes budgétaires => classe PosteBudgetaire

Maintenant, il est évident qu'une Operation fait référence à un Compte, ainsi qu'à un MoyenPaiement et (au moins) un PosteBudgetaire.

Quels sont les bonnes pratiques pour faire ce référencement ?
Par exemple pour le Compte :
- Stocker l'ID du compte dans l'Operation ?
- Stocker carrément un objet Compte dans l'objet Operation ? Ca me paraît plus pratique, mais ça se fait ? Y'a des inconvénients ou limitations ?


Merci :)

salut

Pour le dev objet tu peux penser de cette façon pour savoir si tu dois hériter d'une classe ou référence une classe.

Ma class est un : pour l’héritage -> classe fille
Ma class a un : pour la référence -> objet dans ta classe

Avant de penser objet, tu devrais d'abord poser ton diagramme des classes (ta BDD) afin d'y mettre les liens nécessaires (ce qu'on appel clès étrangères).

Une fois cela fait, tes classes découleront toutes seules de ceci ... ;)

Oui, tant qu'à faire de l'objet, analyse et conception, surtout si c'est pour apprendre, autant partir du début, l'UML.
L'UML est à la POO ce que Merise était à la base de données relationnelles, l'architecture.
topcased UML est un bon logiciel (gratuit) pour faire tes diagrammes, éditeur de diagrammes UML.
Au moins le diagramme des use case et celui des classes.
Bien sûr, UML, ça fait un sacré détour, mais c'est la racine de la conception objet.

Pour la théorie, j'ai trouvé ceci qui devrait bien te mettre le pied à l'étrier et avec ton TP (classique mais ambitieux, le coup de la banque) tu vas pouvoir manipuler les concepts, parce que UML, si l'on ne fait que lire, c'est soporifique. Dans tous les cas, prendre des topos sur UML2.

http://lipn.univ-paris13.fr/~gerard/...urs-slides.pdf

Merci pour vos réponses :-)
Côté BDD et relations je maîtrise (c'est mon boulot :lol:). Du coup je fais le rapprochement avec les classes, les références, tout ça... grâce à votre aide ! Merci encore :mrgreen: