Discussion :

[Kyrel]

Bonjour,

Je commence à raffiner le diagramme de classe du domaine de ma future appli dans le but de le transformer doucement en diagramme d'implémentation. Je me concentre notamment sur le choix des structures de données.

Dans mon modèle, j'ai ce truc (un peu long à charger ) :

Soit une association n-aire, finalement non ?

A votre avis, le plus judicieux serait :
1°/ d'implémenter une classe Ligne de commande (contenant la quantité et une référence sur une instance de Poste et d'Article) et une collection de Lignes de Commandes dans Affaire.
2°/ de fusionner Ligne de Commande et Poste, avec dans poste une collection de paires (quantité, Article) et d'ajouter une collection de Poste dans Affaire
3°/ de faire un truc auquel je n'ai pas pensé : lequel ?
4°/ d'attendre que ca passe.

Merci

[hed62]

4°/ !




Plus sérieusement, je pense que garder "Poste" n'est pas une erreur, dans le sens où un poste peut potentiellement être attaché à autre chose.

Je pense que la transcription directe de ce diagramme en classes et bonne.

[Kyrel]

Merci pour ta réponse, elle m'a permis d'attaquer le problème sous un angle différent.

Un poste n'est en fait caractérisé que par son nom, et ne sert qu'à segmenter la commande. Concrètement, il représente une entité physique à laquelle devra être intégré un article. C'est tout à fait spécifique à une affaire donnée.

[...] poste peut potentiellement être attaché à autre chose.

Comme je le dis plus haut, le poste n'est lié qu'à une seule affaire et ne sert qu'a organiser une commande. Si l'on aborde le problème dans une optique BDD, en considérant une table "Ligne de Commande", chaque tuple serait caractérisé par la clé primaire (poste, référence d'article) ; avec "référence d'article" comme clé étrangère vers la clé primaire du même nom de la table "Articles".

Tu supposes que peut-être dans l'avenir il me serait utile de compléter Poste où de l'utiliser dans un autre contexte. Actuellement, ce n'est pas le cas, et bien que ce soit possible, c'est tout de même peu probable.

Ceci étant posé, le fait de conserver Poste en tant que classe me permettrait de faciliter l'ajout de fonctionnalités, mais alourdirait un peu l'implémentation présente, non ?

Alors quelle est le critère le plus important : l'extensibilité où un code plus compact et "fluide" (au sens d'une navigation entre les objets plus aisée) ?

[hed62]

Pour choisir, il faut peser le pour et le contre :

Si tu garde la classe Poste, tu gagne en effet en extensibilité, mais aussi en taille de base : tu ne répète que l'id du poste dans tes lignes de commande, pas le nom. Ca facilite aussi les modifications en cas de renommage d'un poste.
D'un autre coté, cela entraine une navigation suplémentaire dan tes objets, ce que tu peux aisément masquer en ajoutant (au niveau implémentation) une propriété dans LigneCommande, qui appelera Poste de manière transparente.

Je te propose de conserver Poste, et d'en faire une table de référentielle : une table de paramètrage qui ne varie presque jamais, mais qui permet de paramétrer tes commandes.

D'un autre coté, est ce bien à une ligne de commande de porter ce Poste ? Ce ne serait pas une relation entre Article et Commande (ou ligne) ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Commande <>--> LigneCommande --> Article
|                                  |
|----------------------------------|
            .
            .
          Poste

?

[Kyrel]

Merci pour ta réponse, voilà la mienne, un peu tardive (les études passent devant les projets persos, même si elles sont moins rentables financièrement sur le court terme ).

Bref, je vais effectivement choisir de conserver Poste. Ce qui m'a convaincu ? La facilité de renommage.

Ceci étant clarifié, je peux maintenant tout changer ! Explication : mon client a formulé un nouveau cas et le modèle doit être retravaillé... L'appli doit pouvoir gérer les aléas de chantier, à savoir un client qui n'a pas commandé ce qu'il voulait et commande de nouveaux articles/en retourne une partie.

[hed62]

Eh oui bienvenue dans le monde merveilleux des clients réels qui ne savent pas forcément ce qu'il veulent, ou ne te le dise pas entièrement, ou que tu n'arrive pas à comprendre, ou que tu comprend de travers, ou que tu concois de travers, ou tu implémente de travers .... Bon je sors !