[Débat] modèles full OO et sources de données, est-ce un mythe?

[OneEyedJack]

Envoyé par arkhamon

suffit ?
Pourquoi compliquer à outrance et finir par rendre un code trop complexe ?
[..] Faut arréter la m........ intellectuelle...

On peut même allez plus loin :

Code :

1
2
3
main {
  print( 2+1 );
}

Voire :

Code :

1
2
3
main {
  print( 3 );
}

Oui, tu as raison, arrêtons...

Dans ton exemple, c'est difficile de trouver un intérêt à l'OO dans la mesure où la complexité n'est pas exprimé, On ne sais pas ce que veulent dire Foo et bar . Maintenant, il serait intéressant de discuter du contexte.

• Quel est le périmètre de responsabilité de Foo ?
• Pourquoi une telle addition ?
• Additionne-t-on des litres ? des mètres cubes ? les deux ?
• Faut-il associer un système métrique ?
• Additionne-ton des euros et des dollars ?
• Faut-il associer un convertisseur de devises ? comment y accéder ?

Quand on va commencer à répondre à ces questions, l'exemple prendra de la consistance et on pourrait envisager une réponse plus proche du besoin. D'ici là, l'objectif était que la fonction main est d'afficher 3... et le print(3)...

[OneEyedJack]

Envoyé par souviron34

nous sommes d'accord, mais ça n'est pas ce qui transparait d'expressions comme celles citées plus haut...

Je te suggère de relire mon post. La question posée : les systèmes OO tels que décrit par M. Fowler existent-t-ils ?
En substance, le contenu de mon post :

• oui et j'en ai fait.
• les objets sont inertes si on décide de les considérer comme tels -- Et jusqu'à preuve du contraire, je n'autorise personne à penser à ma place dans ma tête
• il n'est pas rare contrairement à ce qui a été dit de tomber sur de tels système
• L'abstraction et l'OO, à ma connaissance, sont ce que l'on a fait de mieux pour traiter de la complexité des systèmes. -- Encore une fois, si tu as des faits (et non pas des opinions) qui contredisent ce point n'hésite pas à communiquer sur le sujet
• Le procédural et l'OO sont 2 modèles très respectables qui obéissent à des regles différentes

Je ne vois pas dans ce que j'ai écrit quoi que ce soit qui laisse penser que "ça n'est pas ce qui transparaît d'expressions comme celles citées plus haut"

Envoyé par souviron34

je te référerais encore une fois à l'excellent post cité en lien dans le lien du précédent post..
Je pense que son exposé y est très clair..
Il expose très simplement les modes de pensées, et moi, en tant que physicien d'origine, comme nombre de gens ayant ce style de "background", il m'apparait totalement naturel qu'une fonctionalité s'applique à un objet, et non pas qu'un objet fasse une action. De même qu'à tous les techniciens de maintenance avec qui j'ai eu affaire... (trace(symbole), trace(texte), et non pas texte.trace ou symbole.trace).

Lorsque je regarde mon lecteur DVD, je pense que la fonctionnalité de lecture est dans le lecteur et non pas quelque part dans l'éther. Je peux bénéficier de cette fonctionnalité avec la télécommande qui finalement n'est qu'une interface. L'intelligence permettant au lecteur DVD de lire un DVD réside dans le DVD et non pas dans la télécommande et encore moins dans ma main qui actionne la télécommande. Mais je comprends que cela puisse heurter quelqu'un, même s'il est physicien. Ce que tu appelles fonctionnalité, l'OO l'appelle un comportement. Et un principe de d'objet consiste à identifier celui qui supporte le comportement en question et ce n'est certainement pas l'éther.

Pour implémenter un comportement avec un langage OO, on utilise des méthodes qui siègent à l'endroit (la classe) le plus pertinent.
Lorsque l'on explique ce que c'est qu'une méthode à quelqu'un, on essaie d'utilise des images en s'appuyant sur quelque chose qu'il connait :
ben, une méthode, c'est un peu comme un fonction...

Voilà, le vers est dans le fruit, ce qui au départ n'est qu'une approximation pédagogique, se transforme rapidement en "ces idiot d'intégristes de l'OO passent leur temps à inventer des nouveaux termes pour noyer le poisson, c'est de la m... intellectuelle".

Simplicité... quand tu nous tiens...

Pour reprendre l'exemple du lecteur DVD, il dispose de tout un tas d'autres comportements qui sont non visibles (encapsulés), une capacité à allumer et éteindre le laser de lecture, une capacité à faire tourner un disque, etc... L’intérêt de tout çà, c'est que je n'ai pas besoin de connaitre tous ces comportements internes pour regarder un bon film.
Une fonctionnalité, c'est l'idée d'un usage potentiel :

• qu'elle est la fonctionnalité d'une chaise ? on peut s’asseoir dessus
• qu'elle est la fonctionnalité d'un lecteur de DVD ? çà permet de regarder des films

Envoyé par souviron34

ça ne veut pas dire que l'OO ou que la construction OO est absurde, simplement que la logique que vous y voyez n'est pas partagée par tout le monde, et que l'autre logique est tout aussi valable, et plus répandue que dans le seul monde informatique, c'est tout... (demande à un facteur ou à un guichetier à la poste si "une enveloppe se poste" et tu verras sa réponse).

Ben oui, je le vois bien. Et je ne connais aucune idée partagée par l'ensemble des 7 milliards d'individus qui peuple notre planète. Et pour autant lorsque je rencontre quelqu'un qui pense différemment de moi, je ne le considère pas comme un intégriste.

Prenons la physique, un exemple approprié. La théorie des cordes est vue par certains comme un moyen d'unifier l'ensemble des forces de la nature, le rêve d'Einstein. Certains physiciens qui n'adhèrent pas à ces idées considèrent les autres comme des charlatans. Il seront peut-être d'accord un jour, il est normal d'avoir des débats.

Dans l'exemple que je prenais, le rapport entre enveloppe et lettre est le même rapport qu'entre :

• contenant et contenu,
• l'assiette et le cassoulet,
• le verre et la bière.

Mais je respecte les personnes qui ne font pas la différence tous simplement parce tous ces points de vues sont respectables et coexistent dès lors que l'on est en mesure de les justifier. Certains mots désignent d'ailleurs à la fois le contenant et le contenu, c'est le cas de la paella qui désigne à la fois la poêle et le contenu de l'assiette.

C'est ce qui fait que les choses sont complexes, que notre monde est complexe et que l'on peut les observer sous plusieurs angles et découvrir des choses nouvelles. Dans le cas de la lettre et du distingo lettre/enveloppe, l'un et l'autre peuvent se justifier. Dans la mesure où je n'ai pas justifié mon choix (le distingo en question) je dirais que j'ai tord et que je n'ai pas respecté le principe de simplicité (j'ai introduit un concept inutile car non justifié, j'ai augmenté la complication mais pas la complexité)

Ces idées ne sont pas nouvelles et je ne développerai pas plus, on les retrouve dans des choses très différentes comme le cubisme, le bouddhisme, la psychanalyse ou la systémique : la réalité prend plusieurs (poly) formes (morphie).

Qu'est-ce qu'une personne pour une banque ?

• une cible de conquète pour le marketing
• un numéro de compte pour certains
• un client pour d'autres
• un risque quelquefois

La réalité est loin d'être simple. Surtout s'il faut intégrer avec un batch des infos en provenance du marketing, du service client, du département d'étude des risques etc,... le tout en préservant une cohérence sur laquelle peu de gens sont en mesure de se prononcer.

Tiens un autre exemple, la lumière, onde ou particule ?
Certains penchaient pour l'un d'autres pour l'autre pour finalement accepter que c'est les deux. Certains voient le monde qui nous entoure à l'aune de la machine de Von Neumann. D'autres voient le monde à l'aune de la systémique. Qui a tord, qui a raison ?

Tout cela est du ressort d'abstractions qui, quelques soient nos efforts restent bien éloignées de la réalité, ma réalité, celle de mon voisin et celle des physiciens. L'important, c'est de donner du sens quelle que soit notre façon de penser et toujours en conformité avec les exigences techniques, fonctionnelles, organisationnelles, qualitatives... En ce qui me concerne, Von Neumann n'est pas le filtre par lequel j'observe le monde qui m'entoure. D'autres observent le monde par le filtre du capitalisme, le bouddhisme,... Qui a tord ? tous.

"Un homme sage ne croit que la moitié de ce qu'il lit"
on pourrait ajouter :
"un homme sage ne croit que le quart de ce qu'il lit en diagonale"
"un homme sage ne croit que la moitié de ce qu'il écrit, lorsqu'il lui arrive de se relire"
"un homme sage, même plus sage aura du mal à retrouver ce qu'il doit croire dans ce qu'il a écrit"

Envoyé par souviron34

ça n'est qu'un outil, et on en a fait une philosophie... Là est tout le problème....

Oui, j'ai bien noté la physique c'est bien, la philo c'est mal... en l’occurrence c'est pas de la philo, c'est de la systémique

Envoyé par souviron34

moi aussi, et en procédural...

Enchanté de l'apprendre, mais on en attendait pas mois de toi.

Envoyé par souviron34

Donc, comme dis plus haut, il n'y a pas de préférences..

Simplement, le but de tout ce toutim qu'on a eu à propos de l'OO éait que ça simplifiait et était limpide.... à l'opposé du procédural qui aurait été un vaste plat de spaghettis.. Et que la maintenance allait en devenir du coup quasi-instantanée...

A l'évidence ce n'est pas le cas, c'est tout...

Oui, le monde n'est pas parfait et c'est bien triste, j'ai même entendu parler d'endroit où les gens s’entre-tuent...

Envoyé par souviron34

Certains projets sont bien faits en OO, d'autres sont bien faits en procédural.. D'autres le sont mal dans l'un ou l'autre...

Mais on peut très bien ne pas maitriser ni avoir comme but de maitriser le polymorphisme ou la surcharge et produire un code ou un projet excellent..

Je vois qu'on est fait pour s'entendre

Envoyé par souviron34

Comme je suis un adepte forcené de l'Agilité, au sens du Manifeste et pas des méthodolgies qui s'en insprirent, je pense profondément que tout dépend de l'humain, et que malheureusement l'écrasante majorité des dits "informaticiens" formés par nos charmantes universités n'ont été formés que comme de simples techniciens... A qui du coup on fait ingurgiter et recracher des concepts et des théories, en oubliant le bon sens...

Tout à fait d'accord avec toi. L'humain est primordial et j'ai effectivement eu l'occasion de constater que certaines écoles (pas toutes) produisent des techniciens supérieurs mais à bac+5.

Envoyé par souviron34

Or le bon sens du coup part (trop) souvent à vau-l'eau, et on obtient finalement des usines à gaz pour simplement avoir voulu coller à un modèle.. (va juste voir dans le forum à côté (qui maintenant s'appelle ALM) côté conceptions, schémas, patterns, et autres architectures, le fouillis et les questionnements sans fin sur "où ça se place", etc etc.. ça veut bien dire que la "logique" n'est pas si logique que ça)

Le bon sens est vraisemblablement l'une des choses les moins bien distribuées sur la planète

[chaplin]

Envoyé par OneEyedJack

Dans l'exemple que je prenais, le rapport entre enveloppe et lettre est le même rapport qu'entre :

• contenant et contenu,
• l'assiette et le cassoulet,
• le verre et la bière.

Mais je respecte les personnes qui ne font pas la différence tous simplement parce tous ces points de vues sont respectables et coexistent dès lors que l'on est en mesure de les justifier.

Le contre exemple est la carte postale, mais l'objectif n'est pas de polémiquer, c'est que la réalité est accompagnée d'exception. Du coup, je comprends mieux cette dernière phrase .

Certains mots désignent d'ailleurs à la fois le contenant et le contenu, c'est le cas de la paella qui désigne à la fois la poêle et le contenu de l'assiette.

Le danger du discours philosophique est de noyer le poisson dans l'eau, et avec des personnes qui manquent de bon sens, la programmation objet devient une vraie torture.

[el_slapper]

Envoyé par OneEyedJack

(.../...)

• L'abstraction et l'OO, à ma connaissance, sont ce que l'on a fait de mieux pour traiter de la complexité des systèmes. -- Encore une fois, si tu as des faits (et non pas des opinions) qui contredisent ce point n'hésite pas à communiquer sur le sujet

(.../...)

Tout est là-dedans, en fait. Avec 2 choses.

(1)L'abstraction. L'abstraction permet de gérer la complication, la complexité, la quantité, la masse, tant à la création qu'à la maintenance. Je crois qu'on est tous d'accord jusque là.

C'est pourquoi Steve McConnell considère la routine comme la plus grande invention de la science informatique - juste après l'ordinateur, évidemment.

Ce qui nous amène à :

(2)L'objet. L'objet est une forme parmi d'autres de routines, fonctions, procédures, paragraphe appelé par GOTO(oui c'est une routine, oui c'est moche)..... L'objet a ceci d'unique qu'il groupe, en un seul espace de codage, la donnée et les routines associées à cette donnée. Quand on appelle une fonction ou une procédure, au contraire, la routine est délocalisée par rapport à la donnée traitée.

Ce qui offre de nombreuses possibilités, tel l'héritage. Mais la plupart des autres possibilités soi-disant objet, tel le polymorphisme, sont parfaitement possibles en procédural ou en fonctionnel. Une fonction, dans certains langages, peut être surchargée suivant le type de l'élément passé en paramètre. C'est une forme de polymorphisme.

Mais celà pose aussi une limite : toute manipulation d'une donnée doit, dans une conception objet, appartenir à cette donnée. Cette limite est bourrée d'avantages(encapsulation) et d'inconvénients.

Surtout, je ferais la différence entre complication et complexité. La complication, c'est quand une opération unitaire est compliquée. La complexité, c'est quand l'enchevêtrement d'opérations(simples ou compliquées) est compliqué.

L'exemple que tu nous a donné de gestion du planning est compliqué : on a trois opérations qui se battent en duel, mais elles sont extrêmement compliquées chacune. C'est, à mon sens, le domaine ou l'objet doit briller. Sa manière de gérer l'abstraction permet des architectures qui se mappent bien sur le problème.

Par contre, sur des traitements de grande complexité, ou les opérations deviennent innombrables, et surtout peuvent changer de nature fréquemment(un grand classique en bancaire), je reste circonspect sur la pertinence du modèle objet.

Et, dans le cas d'une complexité sans complication, je pense même que c'est completement contre-productif. Souviron34 disait il y a quelque temps qu'on ne fait pas quelquechose d'extraordinaire avec des gens ordinaires. Je suis d'accord avec lui. Mais on a bien souvent des tâches ordinaires en grand nombre à mettre en place/maintenir. Or l'objet nécéssite plus d'agileté intellectuelle que le procédural. Il va donc mettre en echec des personnes "moyennes" qui suffiraient en procédural(pour peu qu'elles aient une grande rigueur, et un peu d'intelligence quand même). Chaplin a parlé de "bagage mathématique nécéssaire", qui n'est pas, à mon sens, à la portée de tout le monde.

[I_believe_in_code]

Envoyé par OneEyedJack

[*]L'abstraction et l'OO, à ma connaissance, sont ce que l'on a fait de mieux pour traiter de la complexité des systèmes. -- Encore une fois, si tu as des faits (et non pas des opinions) qui contredisent ce point n'hésite pas à communiquer sur le sujet

Pourquoi mettre l'abstraction et l'OO dans le même panier ? C'est précisément là que ta façon de voir les choses est dogmatique.

1- L'abstraction, à ma connaissance, est ce que l'on a fait de mieux pour traiter de la complexité des systèmes.

D'autre part :

2- l'OO est une façon de faire de l'abstraction, qui a ses avantages et ses inconvénients.

Chacun fait ses choix selon son environnement, son expérience et ses connaissances et compétences (qui changent avec l'expérience). Il y a une époque où je pensais systématiquement objet pour faire de l'abstraction ; ce n'est plus le cas aujourd'hui. Je ne code objet plus que marginalement, parce que le plus souvent j'ai une meilleure réponse à apporter, qui est souvent en full procédural, mais pas toujours, et ce n'est pas parce que j'ai plus l'habitude du procédural. J'ai du manger autant des deux...

Faut dire que j'ai codé mes propres bibliothèques pour faire plein de choses, qu'elles sont maintenues et régulièrement enrichies depuis vingt ans pour les plus anciennes, et que leur organisation permet un très haut niveau d'abstraction, OO ou pas, et qu'au bout d'un moment le paradigme choisi en lui-même (s'il y en a un) n'a que peu d'impact sur le résultat.

Faut dire aussi que j'aime bien la programmation fonctionnelle (et même fonctionnelle objet, mais c'est un millième de ce que je code seulement qui est fonctionnel objet), ce qui ouvre d'autres perspectives.

Bref, d'accord pour l'abstraction mais associer systématiquement abstraction à OO (au à tout autre paradigme) c'est arbitraire.

Je ne doute cependant pas que l'OO soit très adapté aux projets sur lesquels tu travailles, mais c'est un autre sujet.

[arkhamon]

Envoyé par I_believe_in_code

Pourquoi mettre l'abstraction et l'OO dans le même panier ? C'est précisément là que ta façon de voir les choses est dogmatique.

1- L'abstraction, à ma connaissance, est ce que l'on a fait de mieux pour traiter de la complexité des systèmes.

D'autre part :

2- l'OO est une façon de faire de l'abstraction, qui a ses avantages et ses inconvénients.

Chacun fait ses choix selon son environnement, son expérience et ses connaissances et compétences (qui changent avec l'expérience). Il y a une époque où je pensais systématiquement objet pour faire de l'abstraction ; ce n'est plus le cas aujourd'hui. Je ne code objet plus que marginalement, parce que le plus souvent j'ai une meilleure réponse à apporter, qui est souvent en full procédural, mais pas toujours, et ce n'est pas parce que j'ai plus l'habitude du procédural. J'ai du manger autant des deux...

Faut dire que j'ai codé mes propres bibliothèques pour faire plein de choses, qu'elles sont maintenues et régulièrement enrichies depuis vingt ans pour les plus anciennes, et que leur organisation permet un très haut niveau d'abstraction, OO ou pas, et qu'au bout d'un moment le paradigme choisi en lui-même (s'il y en a un) n'a que peu d'impact sur le résultat.

Faut dire aussi que j'aime bien la programmation fonctionnelle (et même fonctionnelle objet, mais c'est un millième de ce que je code seulement qui est fonctionnel objet), ce qui ouvre d'autres perspectives.

Bref, d'accord pour l'abstraction mais associer systématiquement abstraction à OO (au à tout autre paradigme) c'est arbitraire.

Je ne doute par cependant pas que l'OO soit très adapté aux projets sur lesquels tu travailles, mais c'est un autre sujet.

Tout à fait d'accord : l'abstraction n'est que la capacité de "cacher" derrière un simple appel un ensemble de choses qui sont "fixes". Et dasn cette optique, n'importe quelle fonction est une abstraction.
Après, il se trouve que l'OO l'utilise. Mais aussi la quasi totalité des langages de développement, assembleur compris.

[rimram31]

Envoyé par el_slapper

...Surtout, je ferais la différence entre complication et complexité....

Tu poses le vrai problème qui est celui de la maîtrise de la complexité (pour moi, la complication, c'est plutôt faire plus compliqué que nécessaire )

Si l'abstraction permet, généralement, de gérer plus efficacement la complexité, elle n'est par contre pas au service d'un projet, au sens où le projet aura besoin de communiquer au sein d'une équipe, des métiers amont et aval. Ils nous est parfois même difficile de revenir sur notre propre code que l'on a écrit il y a quelques semaines, quelques mois, que dire alors des autres participants. On a tous fait l'expérience de découvrir ou avoir a intervenir sur un code existant auquel on a bien du mal a comprendre quelque chose quand son niveau d'abstraction est très élevé.

Quand je pense a l'objet, j'aime bien l'analogie avec un système de menus d'une UI. Imaginez un menu avec 10 niveaux hiérarchiques et où toute action dépendrait d'un autre élément à configurer dans un autre menu lui-même au trente sixième niveau ? C'est a peu près l'effort que l'on doit faire quand on intervient sur un code OO, héritages, polymorphies, utilisées a tous les étages, c'est ensuite être contraint d'avoir en tête toutes les classes et les méthodes d'un système complet pour y faire la moindre modification.

Ca n'est pas propre a l'OO et on peut le rencontrer en procédural, on a pas attendu l'objet pour faire de l'encapsulation et de la réutilisation, mais c'est vrai que l'objet y pousse plus naturellement. C'est pourquoi, de mon point de vue, l'objet m'a plus apporté en facilitant les compositions que pour ce qui est de l'héritage ou du polymorphisme qu'il faut utiliser avec modération.

[Nemek]

Je rebondis simplement sur mes exemples qui visiblement n'ont pas été compris ...

Envoyé par arkhamon

Au risque de me répéter, quel est l'interêt (autre que dogmatique bien sur, le dogme étant par définition l'inverse de l'évolution) de faire :

Code :

ou

Code :

ou

Code :

quand un simple

Code :

suffit ?
Pourquoi compliquer à outrance et finir par rendre un code trop complexe ?
Chasser la mouche au canon de 406 c'est très élégant, c'est spectaculaire quand ça fonctionne, mais ne serait-ce pas un poil disproportionné ?
Dans le code ci-dessus, le but est d'ajouter deux entiers et d'afficher le résultat. Il est ou le besoin de créer une instance d'un objet ?
Sans parler du temps d'exécution et de la mémoire utilisée (et des fuites de la sus-nommée mémoire...

Pour planter le Gobelin dnas le sol, la massue du Troll suffit.
Pour planter le clou, faut passer au marteau.
Pour fermer une culasse, il faut une clé dynamométrique...

Normalement, pas besoin de développer plus, un autre l'a dit dans la suite de ce fil : le bon outil pour la bonne tâche...

Faut arréter la m........ intellectuelle...

Les exemples sont des exemples et doivent le rester ... Sinon ma première remarque n'aurait même pas été pour la complexité mais sur la pertinence de la nomenclature ...
Cet exemple ci visait à simplement mettre en évidence qu'à un certain niveau d'abstraction qui n'est pas élevé du tout, il n'y a aucune différence entre procédurale et OO.
Par ailleurs, il suffit de regarder un code C++ désassemblé, c'est un code en C ... Les méthodes sont devenues des fonctions dont le nom est basé sur les noms du namespace, de la classe et de la méthode.
Le polymorphisme se gère directement avec des pointeurs de fonction... Bref ce qui est montré dans mes exemples.

L'OO n'offre rien que ne puisse faire le procédurale et ceux même au niveau de la modélisation PIM. Ce serait (un peu) moins vrai pour le fonctionnel ou le logique. Et 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.
D'ailleurs si on approfondi l'analyse, nombre de design pattern sont basés sur "les pointeurs de fonction" : Visiteur, Observateur, Stratégie, Commande, Fonction de rappel, etc.

[rimram31]

Envoyé par Nemek

L'OO n'offre rien que ne puisse faire le procédurale ...

Ca en amusera peut-être quelques uns: http://fr.wikipedia.org/wiki/Ooc_%28langage%29 ça n'en fait pas du C++ pour autant mais comme quoi on peut faire "de l'objet" en C

[OneEyedJack]

Envoyé par Nemek

L'OO n'offre rien que ne puisse faire le procédurale [...] D'ailleurs si on approfondi l'analyse, nombre de design pattern sont basés sur "les pointeurs de fonction" : Visiteur, Observateur, Stratégie, Commande, Fonction de rappel, etc.

J'ai déjà précisé ce point dans un post précédent : on peut faire pareil en OO qu'en procédural, c'est souvent plus cher en procédural.

Il est d'ailleurs amusant de noter que dans certains langages OO, 1+2, c'est de l'objet... '1' est une instance de Integer, '+' est une méthode de Integer, '2' est une instance de Integer passée en paramètre à la méthode '+'. Donc pas de problème : "Console show: 1+2" c'est bien de l'OO.

[OneEyedJack]

Envoyé par rimram31

Ca en amusera peut-être quelques uns: http://fr.wikipedia.org/wiki/Ooc_%28langage%29 ça n'en fait pas du C++ pour autant mais comme quoi on peut faire "de l'objet" en C

On est tous d'accord. D'ailleurs, dans les premières tentatives de définition du langage C++, c'était du C avec une bibliothèque de macros pour faciliter l'écriture...

[OneEyedJack]

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

Un bazar vend des produits, malheureusement, ces derniers se dégradent en qualité au fur et à mesure que le temps passe. Le système que vous devez développer doit mettre à jour l'ensemble des produits jour après jour (un batch, quoi)

• Tous les articles ont un nom
• Tous les articles ont une valeur (int) qui indique le nombre de jours avant péremption.
• Tous les articles ont une valeur (int) qui indique la qualité de l'objet en vente
• A la fin de chaque journée, votre système doit calculer les deux valeurs pour chaque produit

Jusque là, çà va plutôt bien. Voici l'inventaire du bazard (pour chaque produit : nom/péremption/qualité) :

• "Vieux Cantal" , 2, 0
• "Backstage pass pour le concert des Rolling Stones", 15, 20
• "Marteau de Thor" , 0, 80
• "Botte de radis" , 3, 5
• "Bouteille de lait" , 5, 10

Quelques règles qui s'appliquent :

• Lorsque la date de vente est dépassée, la qualité décroit deux fois plus vite
• La qualité d'un produit n'est jamais négative
• La qualité du vieux Cantal augmente au fur et à mesure que le temps passe
• La qualité d'un produit ne peut aller au delà de 50
• Le Marteau de Thor n'a pas de date de péremption et sa qualité est inaltérable (ben, c'est quand même le marteau de Thor, quoi ?)
• Le pass pour le concert, comme le vieux Cantal, augmente en qualité de 1 chaque jour à ceci près que lorsqu'il reste 10 jours ou moins avant le concert, elle augmente de 2. Lorsqu'il reste 6 jours ou moins avant le concert, elle augmente de 3. Après le concert, la qualité tombe à 0.

Alors, à vos claviers, vous pouvez développer un bon vieux batch avec le langage de votre choix. Vous pouvez prendre :

• un langage procédural et développer procédural,
• un langage procédural et développer OO 100% pas puriste,
• un langage procédural et développer OO 100% puriste,
• un langage OO et développer procédural
• un langage OO et développer OO 100% pas puriste
• un langage OO et développer OO 100% puriste

Pas de contrainte sur les structures de données. Et bien sur, vous pouvez poster votre code. On devrait avoir des commentaires un peu plus constructifs.
Qu'est-ce que vous en pensez ?

[I_believe_in_code]

Vas-y, commence.

[souviron34]

Envoyé par OneEyedJack

J'ai déjà précisé ce point dans un post précédent : on peut faire pareil en OO qu'en procédural, c'est souvent plus cher en procédural.

De mon expérience personelle, tout dépend de ce qu'on appelle "cher".

En termes de nombre de fichiers, de maintenance, et de complexité de compréhension, que ce soit du code ou des répertoires, et de la compil, je penserais l'inverse...

Chacun voit midi à sa porte...

Mais encore une fois tu présentes une opinion comme une vérité...

Quant à tes petits exercices, on n'est ni à ton service, ni là pour prouver que dans un cas ça marche mieux ou pas..

[_skip]

Je ne peux faire l'exercice car malheureusement j'ai suffisamment de boulot comme ça en tant que no 2 dans une start-up.
Cependant ce que je peux dire, c'est que là de nouveau, comme lors de l'exemple précédent, je travaillerai complètement différemment selon que j'utilise une source de données ou non.

Si j'ai tout en mémoire et que je travaille façon "simulation" soit avec une sorte d'horloge ou scheduler qui déclenche les ajustements, je veux bien faire une belle modélisation OO avec des objets métiers qui utilisent des Strategy pour calculer leur plus ou moins-value.

En revanche, si j'ai tout en base de données (genre y'a 200'000 articles) et que j'ai une procédure d'ajustement régulière à coder, Je vais juste charger ces articles dans de simples structures sans intelligence, calculer les ajustements et envoyer des gros batchs. Côté DB ce sera beaucoup plus facile d'organiser tout ça en transactions (au sens ACID) et beaucoup plus efficace que de charger des objets intelligents capables de travailleur sur leurs données de façon autonome puis de les bricoler pour qu'ils participent à la même transaction.
C'est encore plus vrai si les stratégies de vieillissement sont nombreuses, configurables et éditables car cela rajoute des dépendances. Je vois pas chaque article devoir aller charger lui même sa stratégie de péremption dans son coin, ou alors il faut lui donner un fournisseur qui s'occupe de toutes les charger et éventuellement d'utiliser un cache. Quoi qu'il en soit c'est vite beaucoup plus compliqué que la solution entre guillements "procédurale" sans forcément faire gagner grand chose.

Ok ce n'est pas du full-oo domain model si cher aux auteurs de bouquins, pourtant c'est facile à relire, facile à maintenir et le code lui-même documente de façon évidente le processus. Donc pourquoi ce serait faux? Le truc qui a inspiré mon post, c'est qu'à chaque fois que je vois des exemples de modélisation full-oo sur BDD, c'est toujours des exemples de merde avec 5-6 objets simplistes avec des comportements individuels hard-codés et aucune inter-dépendance.

[souviron34]

d'ailleurs même en dehors de BD, tout logiciel manipulant des centaines de milliers d'objets a le même problème.

Exemple : (personnel)

Un SIG censé afficher les éclairs pour la Météo Nationale.. Ah.. Pas de bol.. C'est pas la Météo Nationale française, mais celle du Canada. Le territoire n'est donc pas 1000*1000 km, mais 5000*5000 km (car ce qui se passe aux US intervient).

Une belle journée d'été il y a environ 300 à 500 000 éclairs par heure. Le logiciel est censé afficher ces 500 000 points.

Si ces points sont créés via des "objets", qui chacun a sa méthode "trace", suivant l'occupation du CPU je n'ai pas de contrôle sur qui s'affiche quand..

Or l'information temporelle est essentielle. De plus, un élément de l'affichage doit être des couleurs différentes par tranche de 10 minutes..

Il n'est pas très efficace (c'est le moins qu'on puisse dire) de repasser à travers 500 000 objets alors que tout ce qu'on veut changer de seconde en seconde c'est juste la couleur des objets se situant "à la frontière" de ces bins temporels.. (peut-être 0.5% au grand maximum des points).

Si ma modélisation est tout OO, je suis forcé de passer à travers tous les objets à chaque "update" visuel.. Au vu du nombre, il me faut une super-machine pour pouvoir le faire en moins d'une seconde (d'autant plus que j'ai plein d'autres choses à faire pendant cette seconde)




Maintenant, du point de vue de la BD :

J'ai des BD réparties dans le monde (les divers centres de météo). Un type de donnée manipulé par les utilisateurs est par exemple "la température".

Suivant les bases de données, c'est un point (stations au sol), un vecteur 3D (ballon sonde), un plan ou un volume (modèles numériques), une image (satellites IR) .

Quelle devrait être une modélisation full-OO simple, permettant d'avoir un dialogue simple avec les BD, une bibliothèque simple pour fabriquer des serveurs, et une structure simple pour y accèder via une bibliothèque servant à construire des logiciels de requêtes et d'affichage ???????

D'autant plus que ce que je dis ici pour la température est vrai pour toutes les autres données, certaines possédant plusieurs composantes, comme le vent (vitesse et direction), etc etc..., n'ayant pas les mêmes types numériques : certaines données sont des entiers, d'autres des réels, d'autres des chaines de caractères, d'autres encore des booléens ou des images (serveurs de photos extérieures).....

[micka132]

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?
Faudrait que des gens du monde du jeux video nous éclairent la dessus, mais il me semble bien avoir lu une citation d'un des créateurs de la série des Dooms, que même s'il n'aimait pas ca, il était forcé de reconnaitre son utilité pour ses projets futurs[...]

[_skip]

Envoyé par micka132

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?
Faudrait que des gens du monde du jeux video nous éclairent la dessus, mais il me semble bien avoir lu une citation d'un des créateurs de la série des Dooms, que même s'il n'aimait pas ca, il était forcé de reconnaitre son utilité pour ses projets futurs[...]

Non c'est pas du tout ce qu'il a dit... La question est plutôt de savoir si l'objet en question doit posséder ou non en lui-même l'intelligence pour par exemple déterminer son état, s'afficher, ou si c'est plus judicieux de le considérer comme un ensemble de données sur lequel on exécute des manipulations depuis l'extérieur.
Le fait que le dit "objet" soit une classe n'y change pas grand chose, pour prendre ton analogie avec un jeu, il est peu probable que ce soit dans la classe "Epée" qu'on teste l'état du bouton gauche de la souris pour savoir si le joueur attaque, tout autant qu'il est peu probable que celle-ci ait l'intelligence nécessaire pour s'afficher dans le moteur graphique, sans doute non plus qu'elle ne calcule pas non plus elle-même les dégats lors de la collision avec le joueur 2 car à nouveau ceux-ci dépendent d'une foule de facteurs externes, le niveau du joueur, son équipement etc...

Elle aura par contre certainement des méthodes permettant de connaître ses dégats de base, son niveau d'usure actuel, sa probabilité de coût critique etc... dont le système pourra se servir. C'est dans ce sens là qu'il faut le prendre, et non dans le sens langage objet ou pas.

[rimram31]

Envoyé par _skip

...La question est plutôt de savoir si l'objet en question doit posséder ou non en lui-même l'intelligence pour par exemple déterminer son état, s'afficher...

Le souci de l'exemple donné par OneEyedJack est qu'il est scolaire, expose un problème donné sans tenir compte de la réalité d'un projet. Dans la réalité, les questions que l'on va se poser, c'est es-ce que cette description est exhaustive (risque-t-elle de changer ou pas), les règles sont-elles pérennes ou risquent-elles d'être adaptées en cours de projet ou de vie du "programme". Et dans ce cas, quels acteurs sont susceptibles d'intervenir et comment ... comment vais-je planifier mon projet et l'organiser avec mes équipes, qui va faire quoi? comment vont-ils communiquer ...

Bref autant de questions qui impactent l'architecture pour tenir compte des aspects humains et business du "problème". Quand j'ai débuté en Java, j'avais lu un bouquin de Bruce Eckel, "Thinking Java" et un élément m'avait particulièrement parlé, c'était ce qu'il appelle le "Vector of Change", à savoir essayer d'identifier les risques de changement dans mon projet et retravailler mon architecture pour en tenir compte.

C'est ce qui va permettre ensuite, quand on doit retravailler sur le projet, de réduire la "complexité relative" en ayant adapté l'architecture a la nature des interventions qui vont suivre. C'est le défaut que peut avoir une approche OO par trop "puriste" qui va traiter très efficacement le problème a résoudre mais contraindra a se remettre en tête l'intégralité de l'implémentation pour la moindre modification. Ce qui, comme le suggère __skip, plus haut, va se traduire par une augmentation du coût au final dans un cycle de vie, "ordinaire" de tout projet.

[el_slapper]

Envoyé par _skip

+1

Ok ce n'est pas du full-oo domain model si cher aux auteurs de bouquins, pourtant c'est facile à relire, facile à maintenir et le code lui-même documente de façon évidente le processus. Donc pourquoi ce serait faux? Le truc qui a inspiré mon post, c'est qu'à chaque fois que je vois des exemples de modélisation full-oo sur BDD, c'est toujours des exemples de merde avec 5-6 objets simplistes avec des comportements individuels hard-codés et aucune inter-dépendance.

Perso, en tant que spécialiste COBOL-MVS, je suis encore plus bourrin. La base de données, elle sert aux transactions. Pour le batch, je la décharge dans un fichier plat, je la traite, et je la retraite. La nuit, évidemment. Sur nos machines, c'est juste 100 à 200 fois plus performant que de faire des UPDATE partout.

Mon traitement contient donc un bloc de 3 JCL
(1)un JCL de déchargement(le standard, ça prend 5 minutes)
(2)un JCL avec juste un programme dedans(pour l'instant, on a pas besoin de tri. si on a besoin, on l'ajoute en début de ce JCL, pour ne pas polluer)
(3)un JCL de rechargement(le standard, ça prend 5 minutes)

le programme, en gros, lit un fichier, le traite, et l'écrit. Je ne crois pas que la partie lecture-ecriture pose le moindre problème, c'est hyper standard.

Ma définition de fichier est calée sur la définition de la base. Elle ressemblera à

Code :

1
2
3
4
5
6
7
8
9
01 (P)-ENREG.
    05 (P)-LIBELLE              PIC X(80).
    05 (P)-JOURS-AV-PEREMPTION PIC S9(8).
    05 (P)-QUALITE-ACTUELLE      PIC S9(8)
    05 (P)-TYPE-PRODUIT    PIC X(2).
        88 (P)-TYPE-MARTEAU VALUE '00'.
        88 (P)-TYPE-VIEUX-CANTAL VALUE '01'.
        88 (P)-TYPE-CONCERT VALUE '02'.
        88 (P)-TYPE-AUTRE VALUE '03' THRU '99'.

Parceque nulle part nous n'avons de type de donnée(ou d'objet), je l'ai rajouté. Sinon, on le remplace par une analyse du libellé(mais c'est casse-gueule, objet ou pas). Au pire, dans un langage objet, on regardera TypeOf au lieu de stocker la donnée(mais c'est quand même une forme de stockage).

Mon paragraphe principal ressemblera à :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
PRINCIPAL.
    PERFORM OUVERTURE-FICHIERS
    PERFORM TRAITEMENT-FICHIER UNTIL FIN-FICHIER
    PERFORM FERMETURE-FICHIER
    .


TRAITEMENT-FICHIER.
    PERFORM LECTURE
    IF NOT FIN-FICHIER
        EVALUATE TRUE
            WHEN ENT-TYPE-MARTEAU
                 PERFORM TRAITEMENT-MARTEAU
            WHEN ENT-VIEUX-CANTAL
                 PERFORM TRAITEMENT-VIEUX-CANTAL
            WHEN ENT-CONCERT
                 PERFORM TRAITEMENT-CONCERT
            WHEN ENT-TYPE-AUTRE
                 PERFORM TRAITEMENT-NORMAL
            WHEN OTHER
                 PERFORM ERREUR
        END-EVALUATE
        PERFORM VERIFICATION-QUALITE    
        PERFORM ECRITURE
    END-IF
    .

**************************************
VERIFICATION-QUALITE.
    IF SOR-QUALITE-ACTUELLE < ZERO 
        MOVE ZERO TO SOR-QUALITE-ACTUELLE
    END-IF
    IF SOR-QUALITE-ACTUELLE > 50
        MOVE 50 TO SOR-QUALITE-ACTUELLE
    END-IF
    .
**************************************
TRAITEMENT-MARTEAU.
    MOVE ENT-ENREG TO SOR-ENREG
    .
**************************************
TRAITEMENT-VIEUX-CANTAL.
    MOVE ENT-ENREG TO SOR-ENREG
    SUBTRACT 1 FROM SOR-JOURS-AV-PEREMPTION
    ADD 1 TO SOR-QUALITE
    .
**************************************
TRAITEMENT-CONCERT.
    MOVE ENT-ENREG TO SOR-ENREG
    SUBTRACT 1 FROM SOR-JOURS-AV-PEREMPTION
    EVALUATE TRUE 
        WHEN SOR-JOURS-AV-PEREMPTION > 10
             ADD  1 TO SOR-QUALITE
        WHEN SOR-JOURS-AV-PEREMPTION > 6
             ADD  2 TO SOR-QUALITE
        WHEN SOR-JOURS-AV-PEREMPTION >= ZERO
             ADD  3 TO SOR-QUALITE
        WHEN SOR-JOURS-AV-PEREMPTION < ZERO
             MOVE 0 TO SOR-QUALITE
    END-EVALUATE
    .
**************************************
TRAITEMENT-AUTRE.
    MOVE ENT-ENREG TO SOR-ENREG
    SUBTRACT 1 FROM SOR-JOURS-AV-PEREMPTION
    SUBTRACT 1 FROM SOR-QUALITE
    IF SOR-JOURS-AV-PEREMPTION < ZERO
            SUBTRACT 1 FROM SOR-QUALITE
    END-IF
    .

Je ne me fais pas chier avec les paragraphes de gestion d'erreur ou de fichiers, hein, ils sont méga standards.