Discussion :

[souviron34]

Ca me semble être un problème banal pour un jeux vidéo ton histoire d'éclair de météo.
Si l'on suit ton raisonnement, pour des raisons de rapidité les jeux vidéos ne peuvent fonctionner avec de la POO?

Je ne connais pas les jeux vidéo, mais en ce qui concerne les affichages de fillms, tu peux regarder tous les codes, tu verras que les passages d'une trame à une autre, d'une image à une autre, ainsi que le contrôle de tout ce qui est temporel, se fait en bas niveau, et pas en "objet pur".. Pour des questions évidentes et de rapidité, et de cohérence (quand on a un MPEG par exemple, chaque trame n'est qu'une modification partielle de la trame précédente (MOTION picture). Il parait complexe de faire un objet "trame" avec sa méthode "affiche", nécessitant pour s'exécuter d'obtenir le contenu d'un autre objet "trame"...)

[micka132]

En terme de performance pur il semble évident que de rajouter des couches d'abstraction va ralentir. Ce qui est exposé par OneEyedJack c'est qu'il faut faire un equilibre entre plusieurs paramètres dont le temps de developpement.
Je prend par exemple des logiciels d'ETL comme talend, je l'ai rarement utilisé, mais ce que je constate c'est que très rapidement on peut obtenir des fonctionnalités de dingue. La même chose en C est possible, mais combien de temps il faut pour le faire? On veux changer un branchement combien de temps?
A l'execution j'imagine qu'on ne peut pas rivaliser en terme de performance, mais pourtant si l'on souhaite vraiment optimiser son code C on passe quand même à l'assembleur... Si l'on cherche la performance on va faire de l'assembleur pour autant est-ce qu'on peut se passer de l'abstraction faites par le C? Enfin bon j'ai bien trop peu de recul mais est-ce qu'en terme de délai de developpement et de fonctionnalité demandé à une application tu arrives à comparer des projets objet/non objet? Pourquoi tout les grands editeur s'entete avec cet objet? Se trompent tous t-ils?

[_skip]

Micka, tu te trompes sur la nature du débat, personne n'est en train de parler de C, de java ou d'assembleur ni même de vitesse d'exécution procédural vs objet. La question porte sur des choix de modélisation de traitement qui tous peuvent se faire aussi bien en Java qu'en .net, C++, php, ruby, python ou même C.

[souviron34]

Absolument..

Et bien entendu que cela a des impacts en termes de performances aussi (comme ton post sur les BD et mon post sur les éclairs l'ont montré).

@ mcka:


Tout ce que l'on souligne, c'est que l'approche OO n'est pas forcément la panacée, et peut même être un frein non seulement en termes d'exécution, mais aussi de conception par rapport aux besoins réels d'une appli..

On pourra aboutir à une modélisation qui techniquement serait "propre" en OO, mais avec une réduction drastique des performances, ou de la compréhension, ou une modélisation moins "propre" mais correspondant mieux et aux besoins et aux performances attendues.. Et que du coup cette modélisation "moins propre" peut souvent être faite en procédural plus simplement.. (car ne tordant pas le cou à des concepts de l'OO)

Or les posts auxquels nous répondions, même si l'auteur s'en défendait, prônaient quand même la supériorité de l'OO pur pour des BD et pour une "logique" améliorée.

Nous montrons juste par des contre-exemples que ce n'est pas forcément le cas, et que, comme dans beaucoup de choses et comme il avait été dit plus haut, dans certains cas c'est mieux et plus simple - et performant - dans d'autres cas non...


Comme il a été dit plus haut, l'OO pur se prête parfaitement aux IHM. Pour le reste, ça dépend beaucoup.. Et dès que le problème / les types / les fonctionalités / les volumes sont complexes, cela peut facilement générer des usines à gaz, que ce soit en terme de conception (et donc de maintenance) , ou en termes de performances - et donc de non-rencontre des besoins initiaux.

[Logan Mauzaize]

Bon, en ces temps Halloweenesques je vous propose de chasser le troll un instant avec un petit exemple amusant que j'ai emprunté.[...]

Comme indiqué il s'agit d'un cas d'école, et comme je disais

il n'y avait jamais de mauvaises solutions mais que de mauvais compromis

.
Le problème c'est qu'il y a peu ou pas de contraintes et donc peu ou pas de compromis ...

Donc la meilleure solution :

[...]je suis encore plus bourrin. [...]Pour le batch, je la décharge dans un fichier plat, je la traite[...] La nuit, évidemment.

En terme de performance pur il semble évident que de rajouter des couches d'abstraction va ralentir. Ce qui est exposé par OneEyedJack c'est qu'il faut faire un equilibre entre plusieurs paramètres dont le temps de developpement.[...] Pourquoi tout les grands editeur s'entete avec cet objet? Se trompent tous t-ils?

Tu as soulevé le vrai problème. Et j'en parlais également :

la complication déprendra surtout de l'expérience du développeur : les pointeurs de fonction pour le développeur Objet et l'héritage pour le développeur procédurale.

Le critère de décision n'est pas ce qui est réellement le mieux mais uniquement ce que les gens savent mieux faire. Idem quand tu cites Talend, ca permet de produire un morceau de logiciel à moindre effort (si l'on exclue les efforts initiaux : achat, formation, déploiement, etc). Mais quid de l'efficacité (temps de traitement, résistance aux erreurs, reprise sur erreur, consistance, ACID-ité) ?

Enfin bon j'ai bien trop peu de recul mais est-ce qu'en terme de délai de developpement et de fonctionnalité demandé à une application tu arrives à comparer des projets objet/non objet?

Comme dit précédemment si tu travailles avec des développeurs objets ou (exlusif) non objet, la comparaison est impossible (et inutile). De plus, tu peux rarement te permettre d'analyser un même problème X fois, toujours un problème de prix. Mais lorsqu'il y a des critères plus important que le prix ou que tu sais d'avance qu'on peut faire mieux et faire appel à un "expert", tu peux te permettre une comparaison.

Dans la plupart des problèmes que j'ai vu passer au cours de ma très petite carrière, procédurale ou objet ca revient au même. Tu traites le polymorphisme avec des pointeurs de fonction ou un couple "switch-type". Là où tu peux avoir des différences, c'est surtout sur des traitements d'une autre "dimension" : relationel, logique, etc. Là tu peux avoir de vrai différence à la sortie (temps de traitement, intégrité fonctionnelle, gestion des erreurs, etc.)

[rimram31]

En ce qui concerne le MVC, il a été introduit dans Smalltalk fin des années 70... J'avoue ne pas comprendre pourquoi c'est une aberration du point de vue OO...

Au sens de l'article cité plus haut, qui regrette des objets "sans logique" (le modèle dans un MVC) et j'extrapole dans le sens ou un design "pur OO" aurait intégré les 3 layers en un seul objet.

Je crains aussi de ne pas te suivre lorsque tu dis qu' "il faudrait n'utiliser que du polymorphisme en lieu et place des délégations". Tu peux donner des exemples ?

Il y a eu un grand débat il y a quelques années, notamment a l'arrivée de Java sur l'absence d'héritage multiple vs justement la délégation via les interfaces. En tout cas mon ressenti est que l'OO a d'abord mis en avant l'héritage et le polymorphisme avant la délégation, c'est d'ailleurs assez cohérent avec le premier point.

[yann2]

Bonjour

Je n'ai pas vraiment compris vos exemples. Qu'on fasse du procédural ou de l'OO quand on demande à l'ordinateur de faire du travail inutile. Il le fait !

Donc oui si on dit a un objet trame MPEG : affiche tout le contenu sur l'écran, ouais il va prendre les trames précédentes pour reconstituer une image. Maintenant, si je dis à un un objet trame MPEG : affiche le contenu que tu modifies sur l'écran bah il va afficher que son contenu sur l'écran. C'est quoi le problème exactement ?

Qu'on utilise un paradigme OO ou un paradigme procédural, l'ordinateur lui il s'en fout. Il fait ce qu'on lui dit de faire. Donc jetez la pierre sur le développeur/analyste/architecte et non pas sur le paradigme en lui même. Il ne faut pas jeter le bébé avec l'eau du bain.

D'ailleurs, pour l'exemple de départ, il est évident qu'un object Commande n'a pas à connaitre les stocks. Est ce que, pour autant, cet objet ne doit pas avoir une méthode ajouter produit ? Bah si ! Commande peut avoir une méthode ajouterProduit sauf que ce n'est pas à cet objet de vérifier les stocks ! Dans notre exemple on aura plutôt un objet Stock avec une belle méthode hasProduit(Produit) qui n'a pas à être appelée quand on ajoute un produit à une Commande. Le stock n'est pas mis à jour quand on ajoute un produit à une commande. Il est mis à jour quand une commande est validée. Donc, vérifier les stocks à l'ajout d'un produit n'est pas très efficace. On aura un service validCommand qui n'oubliera pas de vérifier que les produits de la commande sont en stock et les retirera du stock (en passant par des opérations de l'objet stock (stock.hasProduit(), stock.removeProduit()), pas en faisant des stock.getProduits().contains et stock.getProduits().remove()).

D'ailleurs dans le lien donné dans le premier post, Martin Fowler précise bien que d'ajouter du comportement dans des objets ne nous dispense pas d'avoir une couche service. C'est juste qu'elle fait moins de chose, elle est moins intelligente ! (Et il ajoute, fort justement qu'un modèle du domaine n'est pas toujours la meilleure solution... donc là pour le coup ce débat là n'a même pas lieu d'être ). Cette couche va par exemple indiquer la profondeur du graphe à ramené depuis la couche persistance. Ce qui nous évitera de plomber les performances si on doit ajouter un produit sur 10 000 commandes.

Je reviens à Commande.ajouterProduit. Cette opération peut faire plein de chose ! Si, par exemple, une commande ne peut pas avoir plus de 10 produits différents bah elle va pouvoir le vérifier. Une commande connait son client qui connait son pays. Commande.ajouterProduit va pouvoir vérifier que le produit ajouté est bien conforme aux législations en vigueur dans ledit pays (via, par exemple, Pays.isConform(Produit) ou Pays.getLegislation().isConform(Produit), tout dépend de ce qu'on veut faire, il n'y a pas de solution miracle). Bien sûr, on pourrait faire toutes ces vérifications dans un CommandeService.ajouterProduit... mais on perd tout l'avantage de l'OO.

Comme, par exemple : le polymorphisme. Imaginons deux commandes CommandeSimple et CommandeLimitée. CommandeSimple fait juste des vérifications de base sur le produit ajouté. CommandeLimitée elle ne peut pas avoir plus de N produits. Donc on va redéfinir la méthode ajouterProduit dans CommandeLimitée et lancer une belle exception si on tente de dépasser la limite.

Si je fais ce genre de vérifications dans CommandeService.ajouterProduit je suis obligé de vérifier le type de ma commande et de faire les vérifications nécessaires. Et, si on ajoute un nouveau type de Commande bah il faut encore modifier le Service. Comme le Service devient imbuvable (et comme on n'aime pas avoir des instanceof dans nos services) on se dit : on va faire des Stratégies pour faire des vérifications aussi basiques que nbProduits < limiteNbProduits. Donc oui forcément, ça donne une usine à gaz.

Et NON ! L'objet Commande ne doit pas vérifier les stocks, cela ne fait pas partie de ses responsabilités.

Il faut surtout identifier les responsabilités d'un objet. Une commande ne mets pas le stock à jour (quoique ça se discute en fait, une opération Commande.validerCommande() qui prend un objet Stock en paramètre ne me parait pas si aberrant). Autre exemple : une image ne s'affiche pas elle même ou alors, elle le fait de manière intelligente, par exemple pour les composants AWT/Swing : http://www.oracle.com/technetwork/ja...ng-140037.html ! C'est pour ça que je ne comprends pas vos exemple. Qu'on utilise un paradigme procédural ou un paradigme OO, il faut garder le cerveau branché. Décider de redessiner qu'une partie d'un écran ça se fait aussi bien en OO qu'en procédural. Redessiner tout un écran alors que ce n'est pas nécessaire, ça se fait aussi bien en OO qu'en procédural.

A part ça, je veux surtout répondre à la question de départ qui concerne le modèle anémique. Je ne crache pas sur le paradigme procédural.

Yann

[souviron34]

Maintenant, si je dis à un un objet trame MPEG : affiche le contenu que tu modifies sur l'écran bah il va afficher que son contenu sur l'écran. C'est quoi le problème exactement ?

Juste sur ce point, technique : c'est juste que la trame MPEG ne connait pas ni les pixels où elle doit afficher quelque chose ni leurs valeurs..

C'est la définiton du MPEG. Il y a une trame de base une fois tous les X (déterminé par l'algo d'encodage), et les trames suivantes stockent des deltas...

Il est donc strictement impossible pour un objet qui serait "trame MPEG" d'afficher son contenu... Son contenu est purement relatif à ce qui précède.. (sauf la trame particulière "de base", dont on se sait pas où elle se situe..ça dépend des images..)..



Sur le reste, j'ai plus vraiment envie de discuter de ça, nos points de vue ayant été assez clairement exposés.

[yann2]

Juste sur ce point, technique : c'est juste que la trame MPEG ne connait pas ni les pixels où elle doit afficher quelque chose ni leurs valeurs..

C'est la définiton du MPEG. Il y a une trame de base une fois tous les X (déterminé par l'algo d'encodage), et les trames suivantes stockent des deltas...

Il est donc strictement impossible pour un objet qui serait "trame MPEG" d'afficher son contenu... Son contenu est purement relatif à ce qui précède.. (sauf la trame particulière "de base", dont on se sait pas où elle se situe..ça dépend des images..)..

Dans ce cas précis ce n'est pas à l'objet Trame de savoir comment s'afficher, mais un autre objet sera responsable de l'affichage de la trame (un Objet MPEGPlayer par exemple).

Sur le reste, j'ai plus vraiment envie de discuter de ça, nos points de vue ayant été assez clairement exposés.

Je n'ai fait que rappelé un des principes de bases de la POO : le polymorphisme. Il en existe deux autres : l'héritage et l'encapsulation.

[chaplin]

Et NON ! L'objet Commande ne doit pas vérifier les stocks, cela ne fait pas partie de ses responsabilités.

Il faut surtout identifier les responsabilités d'un objet.

C'est la partie la plus difficile en conception, d'identifier la responsabilité d'un objet.

[el_slapper]

Dans ce cas précis ce n'est pas à l'objet Trame de savoir comment s'afficher, mais un autre objet sera responsable de l'affichage de la trame (un Objet MPEGPlayer par exemple).



Je n'ai fait que rappelé un des principes de bases de la POO : le polymorphisme. Il en existe deux autres : l'héritage et l'encapsulation.

Franchement, l'héritage, je veux bien.

le polymorphisme :

Code :

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

1
2
3
4
5
6
7
Function Surface(Donnee as Carre)
   blablablablaCarre
End Function

Function Surface(Donnee as Cercle)
   blablablablaCercle
End Function

C'est de l'objet?

Pourtant, c'est du polymorphisme : la même fonction possède des formes différentes

On peut aussi encapsuler en procédural (ou en fonctionnel). L'objet permet certes de le faire de manière moins contournable, mais des mécanismes existent.

[gl]

le polymorphisme :

Code :

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

1
2
3
4
5
6
7
Function Surface(Donnee as Carre)
   blablablablaCarre
End Function

Function Surface(Donnee as Cercle)
   blablablablaCercle
End Function

C'est de l'objet?

Pourtant, c'est du polymorphisme : la même fonction possède des formes différentes

Je pense qu'il faut prendre dans les explications de yann2 (et d'autres avant lui) le terme polymorphisme dans le sens de polymorphisme de sous-typage (aka polymorphisme d'inclusion). Mais c'est vrai que c'est assez désagréable cette tendance de réduire le polymorphisme au seul polymorphisme d'inclusion alors que c'est infiniment plus vaste et plus riche.

[rimram31]

Dans ce débat, plus que d'opposer OO et procédural, il faudrait opposer OO et agile. Ou j'ai mal compris, ou Martin Fowler semble regretter que les objets n'aient pas "plus de responsabilités" quand l'agile (mais aussi le simple bon sens) au contraire poussera a découper par responsabilité (perso, j'aurai isolé la vérification d'une législation dans l'exemple donné par yann2 ...).

Pour autant si on se tourne vers ses approches, quitte a fabriquer quelques objets "creux", c'est bien que l'OO "pur" a montré ses limites.

[yann2]

Bonjour

Tout d'abord, personnellement, je ne vois pas le rapport avec l'agile dans l'article cité.

Deuxièmement, modèle de domaine anémique = Classe ayant simplement des propriétés. En gros un graphe objet sans comportement. Qu'est ce que ça implique ?

- Pas d'encapsulation du comportement (il n'y en a pas)
- Pas d'encapsulation des données nécessaires à l'implémentation du comportement (l'intelligence est "ailleurs" et donc tout doit être exposé).
- Presque pas d'héritage (on hérite juste des propriétés mais, pas des comportements).
- Pas de polymorphisme (je mets de côté la surcharge qui peut être pratique quand celle ci est résolue dynamiquement mais, ça ne va pas changer la donne de notre problème si c'est résolu statiquement : à la compilation).

Martin Fowler précise qu'en utilisant ce genre de design on obtient :
- les inconvénients du paradigme OO (en donnant l'exemple du mapping Objet-Relationnel)
- sans les avantages du paradigme OO (j'en ai cité plus haut).

On ne parle pas, ici, du langage mais, simplement du paradigme orienté objet.

[souviron34]

On ne parle pas, ici, du langage mais, simplement du paradigme orienté objet.

Oui mais justement :

le paradigme orienté objet est depuis belle lurette implémenté couramment, y compris en procédural bien dur, et tu peux prendre des programmes Fortran ou C des 30 dernières années au minimum, c'est bien programmé avec un paradigme orienté objet..... qui comprendra au minimum encapsulation et héritage...


Ce qui est reproché est à mon sens au contraire les usines à gaz des LANGAGES OO.. et des conceptions associées..


Quant au rapport avec l'agilité, je suis d'accord avec toi cela n'a aucun rapport..

[rimram31]

...Tout d'abord, personnellement, je ne vois pas le rapport avec l'agile dans l'article cité...

Parce qu'un design agile, par principe, créera autant de "layers" que de responsabilités et introduira des objets "anémiques" pour échanger entre ces différents layers et orchestrer le tout ailleurs. En faisant quelques recherches, je suis tombé là dessus: http://philippe.developpez.com/articles/SOLIDdotNet/, le premier refactoring découpe un "objet" en 3 et introduit un simple container getter/setter, sa factory et enfin l'objet contenant la "logique métier", l'idée étant d'avoir découpé par "risque de changement".

J'ai peut-être mal compris l'article de Martin Fowler, mais ça me parait être justement ce qu'il critique. Je sais par contre d'expérience, que oui, en introduisant différents "layers" on a tendance a "remettre a plat" les objets et, ce que je trouve au contraire intéressant, a faire du reuse transverse (exemple d'un layer ORM).

[souviron34]

Parce qu'un design agile, par principe,

Honnêtement je ne sais pas ce que c'est un "design agile"..

Autant je suis d'accord avec toi sur le reste, autant là-dessus, non. L'Agilité n'est en rien liée au design, mais (en partie) à la MANIERE de l'obtenir...


C'est une manière de gérer...

Que je sache, rien à voir avec la manière de coder suivant les langages...

Tu peux faire de l'OO ou du procédural en V, comme en Agile..

[yann2]

Salut

Oui mais justement :

le paradigme orienté objet est depuis belle lurette implémenté couramment, y compris en procédural bien dur, et tu peux prendre des programmes Fortran ou C des 30 dernières années au minimum, c'est bien programmé avec un paradigme orienté objet..... qui comprendra au minimum encapsulation et héritage...


Ce qui est reproché est à mon sens au contraire les usines à gaz des LANGAGES OO.. et des conceptions associées..


Quant au rapport avec l'agilité, je suis d'accord avec toi cela n'a aucun rapport..

Oui, je reste complètement d'accord avec tout ça. De la même manière, il est très simple de faire du procédural avec Java, par exemple. Je ne pense pas que le problème vienne d'un langage OO mais plutôt, comme tu le dis, des conceptions associées. Et, faire un modèle objet + mapping O/R juste pour faire du SELECT / INSERT / UPDATE / DELETE dans une base de données, je trouve que c'est un peu overkill Bon peut être que ça facilite la lecture de l'implémentation des services.

Après... je dis ça mais dans mon expérience en JEE je n'ai vu que des modèles anémiques.

[rimram31]

...C'est une manière de gérer...

J'ai plutôt le sentiment que le thread a dérivé sur un débat OO vs procédural alors que le post initial, en tout cas ce que j'en comprends, parlait de l'intérêt des "service layers". Dans l'exemple de produits et de commandes cité par yann2 plus haut, "l'agile" aura tendance a introduire un gestionnaire de produits, de commandes, de contrôle de conformité a une législation ... et fera tout pour que ces éléments en sachent le moins possible des autres, au risque de perdre certains "bénéfices" de l'objet.

Et in fine, plus tu vas découper en 12 tes objets, plus tu vas te retrouver avec des composants simples, peu de niveau hiérarchique, peu ou pas de polymorphisme et autres spécificités de l'objet.

Edit: @_skip ton post pour moi illustre mon dernier point, ton "design" préfère découper en opérations élémentaires que tu vas ensuite "réassembler" à ta guise ayant en quelque sorte extrait la logique métier.

[_skip]

Donc, vérifier les stocks à l'ajout d'un produit n'est pas très efficace. On aura un service validCommand qui n'oubliera pas de vérifier que les produits de la commande sont en stock et les retirera du stock (en passant par des opérations de l'objet stock (stock.hasProduit(), stock.removeProduit()), pas en faisant des stock.getProduits().contains et stock.getProduits().remove()).

Je dirai que ça dépend de ton cahier des charges, j'ai travaillé pour des comptes ou c'était indispensable d'afficher un gros message d'erreur aussitôt qu'on voulait saisir un poste de commande avec un objet non livrable.
Cela pose également la question du mode de saisie, puisque l'ajout d'une produit peut être considéré comme la transaction, ou alors l'ajout de la commande au système (préparée en mémoire) peut être *la* transaction.

(Et il ajoute, fort justement qu'un modèle du domaine n'est pas toujours la meilleure solution... donc là pour le coup ce débat là n'a même pas lieu d'être ). Cette couche va par exemple indiquer la profondeur du graphe à ramené depuis la couche persistance. Ce qui nous évitera de plomber les performances si on doit ajouter un produit sur 10 000 commandes.

Si, ce débat a au contraire particulièrement lieu d'être dans le sens où on admet qu'il y a des opérations qui passent mieux sous forme fortement objet, et d'autres où un script de transaction plus procédural est mieux adapté. Sans doute que tout le monde pose le taquet à un endroit différent.

Je reviens à Commande.ajouterProduit. Cette opération peut faire plein de chose ! Si, par exemple, une commande ne peut pas avoir plus de 10 produits différents bah elle va pouvoir le vérifier. Une commande connait son client qui connait son pays. Commande.ajouterProduit va pouvoir vérifier que le produit ajouté est bien conforme aux législations en vigueur dans ledit pays (via, par exemple, Pays.isConform(Produit) ou Pays.getLegislation().isConform(Produit), tout dépend de ce qu'on veut faire, il n'y a pas de solution miracle). Bien sûr, on pourrait faire toutes ces vérifications dans un CommandeService.ajouterProduit... mais on perd tout l'avantage de l'OO.

Tu perds l'avantage de l'OO c'est un peu vrai, mais tu as toujours ce souci que les objets plus intelligents doivent se fournir en données et en règles depuis la DB, d'autant plus que ça peut devenir super tordu si tu as un système de fidélisation de clients, ou des conditions particulières au client.

Tu risques vite de lazy loader à outrance, et d'avoir des opérations anodines comme setter une quantité commandé qui déclenche un monstre job derrière. Et tu vas pas forcément toujours faire du eager loading et tout ça doit in-fine correspondre à une transaction au sens DB. Et comment si tu commences à grouper ces opérations, est-ce que t'arriveras à avoir des stratégies de chargement efficaces sans devoir balancer une foule d'indice à ton objet sur la façon dont tu comptes t'en servir?

Perso je ne pense pas qu'un programme doivent impérativement comporter une couche service avec des poignées de méthodes statiques. J'ai eu pas mal de succès en réfléchissant mes applications en terme d'entrée sortie, il y a une UI (forcément avec le client on commence toujours par savoir comment il va bosser puisque malgré tout c'est encore avec lui qu'on définit le besoin et la façon dont on interagit avec le système) qui va déclencher des opérations, ou actions.
Je peux par conséquent tout à fait imaginer une action sous la forme d'une classe qui utilise des services et décompose les différentes vérifications et organise les chargement et les transactiosn DB de la façon la plus appropriée.
En ce sens, je me rapproche d'un système où on modélise l'action plutôt que l'objet au sens "le produit", "la commande". Il est possible de les rendre réutilisable par d'autres plus grosses unités de travail, d'autres UI, etc...

Et donc ça organise aussi ma réflexion sous forme d'opérations qui se révèlent au final assez lisibles et testables. A titre d'exemple, si on me dit que la validation des commandes est une opération qui se fait une fois par jour avec à l'écran une grid récapitulative, une case à cocher, et un bouton valider, je vais considérer une action qui mange en paramètre un tableau de commande, qui charge en 1 requête tout ce qui est nécessaire aux vérifications pour le lot sélectionné et qui organise le boulot en une transaction DB avant de retourner un petit récapitulatif qui pourra être utilisé pour afficher une conformation. Mais j'ai pas d'objet intelligent "Commande" avec une méthode "markValidated()", ça apporterait peu et ça me compliquerait probablement la vie. Cela empêcherait pas d'avoir un objet "Commande" mais d'où on estime qu'il n'a pas à savoir se valider.

Enfin soyons d'accord Yann, je peux pas raisonnablement dire que ce que tu proposes ça marche pas, je dirai que les modélisations que tu proposes ont un gain et en contrepartie un possible sacrifice, surtout à mon sens quand il s'agit de se procurer des données externes qui ne seraient pas toujours nécessaires suivant les opérations. Enfin ce sont des problèmes pas évident, rester sur mon système de transaction par action (qui ressemble un peu à du procédural) me semble correspondre à mes besoins. Cependant je peux tout à fait imaginer qu'il y ait des approches OO bien réfléchies et assez élégantes au final si on s'applique à bien délimiter les choses.