Discussion :

[c0rt0]

Bonjour,

Je travaille actuellement sur un relativement gros projet, et je m’interroge sur les choix de conception qui ont été faits, et les déséquilibres qui en résultent.

Je m’explique, nous développons, pour résumer, une application comptable : des comptes, des écritures, des paiements, des remboursements, des factures, des rappels, etc.

L’élément central du modèle est le compte qui "tient" des collections d’écritures, de paiements, de remboursements, etc.

Jusque là, les choses me paraissent relativement logiques et raisonnables.

Pour chaque élément (écriture, paiement, etc.), on peut les enregistrer, les supprimer, les modifier, etc.
Toutes ces actions auront un impact sur le compte auquel l’élément appartient, il paraît donc aussi raisonnable que ça soit le compte qui ait la responsabilité de toutes ces actions !

Là où les choses me perturbent, c’est qu’au final toute l’intelligence se retrouve dans la classe Compte (qui est gigantesque), et que les classes Ecriture, Paiement, etc. ne sont finalement que des classes techniques visant à être persistées.

Le déséquilibre est donc complet, avec touts les problèmes que cela implique.


Je suis bien conscient du problème, mais je ne vois ni où le raisonnement est faux, ni comment remédier au problème.

Ouala, tout avis sera bon à prendre, merci.

[Keihilin]

Toutes ces actions auront un impact sur le compte auquel l’élément appartient, il paraît donc aussi raisonnable que ça soit le compte qui ait la responsabilité de toutes ces actions !

Situation assez classique, je te rassure.
C'est sans doute particulièrement flagrant dans ton cas, mais il arrive souvent qu'un objet qui tient une position central se retrouve complètement surchargé de responsabilités. En terme de code, on arrive à des objets satellites ne représentant que des données et à un gros objet central de plusieurs milliers de lignes de code qui va devenir difficilement maintenable.

Il n'est pas possible de te proposer quelque chose de concret sans voir les sources, mais une approche possible est de replacer ton objet "Compte" dans la catégorie "objet de données" en supprimant la logique métier qu'il contient
pour ensuite redistribuer cette logique dans diverses classes "Service" qui manipulent un objet "Compte" ou une collection de "Compte".

[Hephaistos007]

En effet c'est classique. On les appelles les "God objects" (http://en.wikipedia.org/wiki/God_object)

[c0rt0]

ok, merci pour vos réponses.

je veux bien croire que c'est un anti-pattern courant, mais y'a-t-il un pattern habituel pour y remédier (la notion de "classe Service" évoquée plus haut fait-elle partie d'un design pattern classique ?)

[alex00]

Bonjour,

L'utilisation de classes de services est assez répandue dans le monde de l'objet, et tend en général a séparer les données des fonctions...
Mais quand on a beaucoup de traitements, on peu rarement faire autrement.

Ceci étant dit, en réfléchissant un petit peu :
- les opérations sur un Compte sont 'ajouter()' et 'retirer()' de l'argent,
- la responsabilité du Compte est de garder l'historique des opérations effectuées (e.g une liste d'Operation).
On peut voir :
- Paiement et Ecriture sont des (héritent de) Operation (avec des dates de valeurs, des montants, et pourquoi pas aussi une liste de modifications).
On a alors :
- un Compte.traite(Operation), ce traitement faisant appel a ajouter() et retirer() qui deviennent privées. Compte ne doit surtout pas connaitre les sous-classes de Operation.

Et chacun reste chez soi.

C'est peut-être un peu simpliste, je ne connais pas ce domaine. Mais l'attribution des responsabilités me semble plus juste.

Qu'en penses-tu ?

[deltree]

Bonjour,
c'est amusant, moi c'est sur les écritures que l'application a fini par être centrée. (i.e. en gros écritures comptables donc les ligne d'opération sur le relevé de compte)

ça doit être lié aux objets qu'on manipule le plus dans l'application, ceci dit chez nous ça s'apparente plus à des "Bean", et c'est le service lié au bean "écritures" qui fait l'essentiel.

ça me semble assez logique étant donné que l'essentiel de l'application sert à la saisie/ l'affichage de virements.

[souviron34]

juste une eptite remarque en passant.....

A vous lire , je suis conforté dans ma position que "l'objet" tel que véhiculé et publicisé et "à la mode" ces derniers temps amène tout autant d'aberrations et d'incohérence que le "non-objet"....



Bonne journée

[Keihilin]

A vous lire , je suis conforté dans ma position que "l'objet" tel que véhiculé et publicisé et "à la mode" ces derniers temps amène tout autant d'aberrations et d'incohérence que le "non-objet"....

1. Je ne pense pas que l'on puisse parler de mode.
2. l'OO n'est de loin pas synonyme de "bon code automatique".
3. l'OO apporte souvent 50 façons différentes de faire la même chose dont souvent au moins 5 recommendables en fonction d'un contexte ou d'une architecture globale...Les possibilités de faire des erreurs de design sont démultipliées !

Cela dit, les avantages de l'OO sur le procédural sont connus, mais à part un idiot d'intégriste, personne ici n'affirme que l'OO est la réponse à tout.