Publicité
+ Répondre à la discussion
Page 5 sur 6 PremièrePremière 123456 DernièreDernière
Affichage des résultats 81 à 100 sur 112
  1. #81
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 183
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 183
    Points : 14 353
    Points
    14 353

    Par défaut

    Citation Envoyé par micka132 Voir le message
    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"...)
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  2. #82
    Membre Expert
    Homme Profil pro Mickael
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    815
    Détails du profil
    Informations personnelles :
    Nom : Homme Mickael
    Âge : 25
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 815
    Points : 1 517
    Points
    1 517

    Par défaut

    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?

  3. #83
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 719
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 719
    Points : 6 864
    Points
    6 864

    Par défaut

    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.

  4. #84
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 183
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 183
    Points : 14 353
    Points
    14 353

    Par défaut

    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.
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  5. #85
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro Logan
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 108
    Détails du profil
    Informations personnelles :
    Nom : Homme Logan
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 108
    Points : 4 735
    Points
    4 735

    Par défaut

    Citation Envoyé par OneEyedJack Voir le message
    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
    Citation Envoyé par Nemek Voir le message
    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 :
    Citation Envoyé par el_slapper Voir le message
    [...]je suis encore plus bourrin. [...]Pour le batch, je la décharge dans un fichier plat, je la traite[...] La nuit, évidemment.
    Citation Envoyé par micka132 Voir le message
    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 :
    Citation Envoyé par Nemek Voir le message
    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é) ?


    Citation Envoyé par micka132 Voir le message
    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.)
    Java : Forum - FAQ - Java SE 8 API - Java EE 7 API
    Articles sur Ceylon : Présentation et installation - Concepts de base - Typage

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  6. #86
    Membre éclairé
    Homme Profil pro
    Directeur de projet
    Inscrit en
    octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : octobre 2012
    Messages : 117
    Points : 321
    Points
    321

    Par défaut

    Citation Envoyé par OneEyedJack Voir le message
    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.
    Citation Envoyé par OneEyedJack Voir le message
    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.

  7. #87
    Membre Expert Avatar de yann2
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2004
    Messages
    806
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2004
    Messages : 806
    Points : 1 277
    Points
    1 277

    Par défaut

    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

  8. #88
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 183
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 183
    Points : 14 353
    Points
    14 353

    Par défaut

    Citation Envoyé par yann2 Voir le message
    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.
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  9. #89
    Membre Expert Avatar de yann2
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2004
    Messages
    806
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2004
    Messages : 806
    Points : 1 277
    Points
    1 277

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    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).

    Citation Envoyé par souviron34 Voir le message
    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.

  10. #90
    Membre Expert Avatar de chaplin
    Inscrit en
    août 2006
    Messages
    1 215
    Détails du profil
    Informations forums :
    Inscription : août 2006
    Messages : 1 215
    Points : 1 574
    Points
    1 574

    Par défaut

    Citation Envoyé par yann2 Voir le message

    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.

  11. #91
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 151
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 151
    Points : 10 326
    Points
    10 326

    Par défaut

    Citation Envoyé par yann2 Voir le message
    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 :
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  12. #92
    gl
    gl est déconnecté
    Rédacteur/Modérateur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 096
    Points : 4 160
    Points
    4 160

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    le polymorphisme :

    Code :
    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.

  13. #93
    Membre éclairé
    Homme Profil pro
    Directeur de projet
    Inscrit en
    octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : octobre 2012
    Messages : 117
    Points : 321
    Points
    321

    Par défaut

    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.

  14. #94
    Membre Expert Avatar de yann2
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2004
    Messages
    806
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2004
    Messages : 806
    Points : 1 277
    Points
    1 277

    Par défaut

    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.

  15. #95
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 183
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 183
    Points : 14 353
    Points
    14 353

    Par défaut

    Citation Envoyé par yann2 Voir le message
    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..
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  16. #96
    Membre éclairé
    Homme Profil pro
    Directeur de projet
    Inscrit en
    octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : octobre 2012
    Messages : 117
    Points : 321
    Points
    321

    Par défaut

    Citation Envoyé par yann2 Voir le message
    ...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).

  17. #97
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 183
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 183
    Points : 14 353
    Points
    14 353

    Par défaut

    Citation Envoyé par rimram31 Voir le message
    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..
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  18. #98
    Membre Expert Avatar de yann2
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2004
    Messages
    806
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2004
    Messages : 806
    Points : 1 277
    Points
    1 277

    Par défaut

    Salut

    Citation Envoyé par souviron34 Voir le message
    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.

  19. #99
    Membre éclairé
    Homme Profil pro
    Directeur de projet
    Inscrit en
    octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : octobre 2012
    Messages : 117
    Points : 321
    Points
    321

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    ...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.

  20. #100
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 719
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 719
    Points : 6 864
    Points
    6 864

    Par défaut

    Citation Envoyé par yann2 Voir le message
    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •