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

[el_slapper]

Envoyé par OneEyedJack

(.../...)
En résumé par rapport à OO vs procédural, il y a du procédural dans l'OO mais il y a aussi des concepts de haut niveau comme le polymorphisme et autres. Ces derniers permettent de construire des abstractions qui constituent des systèmes plus complexes, plus interactifs, plus ergonomiques. Comme cela a été dit dans les différents posts, on peut simuler en C le polymorphisme avec des pointeurs de fonctions et des pointeurs de pointeurs, des macros, etc... mais c'est plus long à écrire et lire, à comprendre, à modifier, il est aussi plus difficile de trouver des personnes compétentes pour monter une équipe projet.
La quantité d'OO par rapport au procédural (si tant est que cette notion de quantité ait un sens) dans un système dépend de la maturité des développeurs et de l'effort que cela leur demande pour le concevoir et le développer.

Mouhahahahaha!!!!!

Bon, alors maintenant, tu vas expliquer à ma MOA bancaire pourquoi quand elle demande à développer un batch, nos chiffrages COBOL(qui incluent les chiantissimes transferts de fichier UNIX vers MVS et vice-versa) sont moitié moins couteux que les chiffrages Java-OO tout le toutim.

Indice 1 : en transactionnel, ça n'est sans doute pas vrai(mais je n'ai pas de billes pour vérifier)
Indice 2 : le temps de développement n'est sans doute pas le principal poids qui pèse sur les épaules des développeurs objet.


Mon hypothèse, c'est que
(1)l'encapsulation des données est particulièrement efficace quand il s'agit de données directement techniques(d'ou l'extrême efficacité pour tout ce qui est transactionnel à écrans complexes), et de données extrêmement standard qui s'encapsulent naturelllent dans des algorithmes compliqués.

(2)En bref, la puissance du polymorphisme s'applique là ou le polymorphisme s'intègre naturellement dans le problème(tautologie qui mérite plus de détails). Mes batches à moi n'ont rien de compliqué. Par contre, ils sont complexes : on a des milliers de petites opérations merdiques, dont les plus compliquées sont de l'ordre de la division, mais avec un enchevetrement de règles interdépendantes. Fonctionellement, tout dépend de tout. C'est pourquoi le modèle objet ou les données sont coupées les unes des autres est assez peu utilisable tel quel.

(3)Ce qui coute cher à mes collègues de l'objet, c'est l'intégration. Par exemple, si ils ont besoin ne serait-ce que d'une seule donnée comptable, ils doivent se trimballer toutes les classes comptables, qui sont toutes plus ou moins interdépendantes. Moi, je vais me servir dans leur fichier, j'ai juste besoin de noter leur définition de données, je compile, et basta. J'en ai pour 5 minutes. Ils en ont pour des jours et des jours à gérer les adhérences.

(4)Pour aller plus loin que le point 3, il me semble que nous, en procédural pur(la couche objet du cobol est désactivée dans nos standards de compilation), nous avons un magma informe de données, mais une séparation stricte des composants. Au pire, la compta change son format de données, fait une étude d'impact(20 minutes), envoie un mail aux applis concernée, et nous recompilons le jour de leur mise en prod(10 minutes par appli).

En objet, il y a une séparation complète des données, au prix d'une dépendance beaucoup plus forte entre les composants. Ca a une qualité évidente : on ne touche pas aux données de la compta sans passer par le code de la compta. Mais aussi un défaut majeur : tout dépend de tout, donc tout le monde interagit avec tout le monde, donc la complexité du système augmente beaucoup plus avec sa taille qu'un bête procédural. Quand bien même je récupère 70% des données de la compta, ma restitution n'est que marginalement dépendante ce que qu'ils peuvent bien faire. Je ne passe jamais par leur code. Je n'ai besoin que du format de leurs données - et il ne change pas tous les 4 matins. Si je plante, c'est de MA faute(mon traitement est pourri), ou alors de LEUR faute(leurs données sont pourries), mais en aucun cas de la faute de l'intégration de leurs objets dans les miens, et autres problème s'intégration dans lesquels je vois mes voisins, tout aussi compétents que moi, se perdre

Clemens Vasters, Jeff Atwood et Paul Graham sont dubitatifs vis-à-vis de l'objet au niveau donnée fonctionnelle.

Envoyé par Clemens Vasters

I just lost faith that objects are any good on the "business logic" abstraction level.

.

L'encapsulation, au niveau fonctionnel bancaire, c'est juste un appel à se fracasser le crâne contre des problèmes qui n'ont pas lieu d'être. Il est bien plus simple de passer un simple paquet contenant les données utiles, et de coder ce qui va bien dessus. Ca a un défaut majeur, que j'ai cité au dessus : on maitrise moins qui travaille sur quoi. Mais vu que la principale difficulté est de trouver des cerveaux capables de gérér toute cette complexité, il me parait contre-productif de se trimballer des encapsulations dans tous les sens pour des modules purement fonctionnels.

Evidemment, si tu me parles de faire un bel écran avec de beaux boutons, mon argumentaire ne tien plus(et dans ce cadre, il m'arrive de faire des objets encapsulés). Mais je parle bel et bien du niveau fonctionnel, celui ou l'opération la plus compliquée(avec 3 exceptions en 12 ans), c'est une division.

[souviron34]

Je rebondirais sur ce que tu dis, avec une partie de ce que tu cites et que j'avais zappée :

Envoyé par OneEyedJack

il est aussi plus difficile de trouver des personnes compétentes pour monter une équipe projet.

Ceic est purement dû à la déification de l'objet faite depuis environ les années 98-99 (poussée de plus par Delphi depuis 93), qui a fait apparaître ringard le C en particulier et la "belle" conception intellectuelle.. et ça n'est en rien dû à une "supériorité supposée" ou "de facto".... Linux (1995) est là pour le prouver...

On manque de main d'oeuvre compétente simplement parce qu'on n'en a pas formé, et qu'on a inculqué de force que C++ (à l'époque) était la panacée (puisque même Delphi et Object-Pascal était ringard). Il suffit de lire une bonne partie du post cité et des autres débats sur ce sujet ici-même pour s'en rendre compte....

D'ailleurs, c'est entretenu par les recruteurs, qui mettent "C/C++" et te jettent quand tu dis "ben moi c'est C"..

Mais il y a 4 ou 5 ans c'était tout simplement une aberration de voulor oser penser à rester en C... Universitaires, étudiants, profs, tout était C++...

(comme la mode de Ruby, de Python, ...)

Alors il est certain que si on veut des petits jeunes, ils n'ont été formés qu'au C++ et à l'objet pur....

Cependant, d'une part les plus vieux ne sont pas dans ce cas, et d'autre part l'envolée de l'embarqué finit (et j'en suis bien content) par remettre au goût du jour des choses comme le C... et donc lui enlever son attribut de "ringardise" pour lui remettre celui de "efficace"...

L'objet est tout à fait adapté à la fabrication d'IHM. Pour le reste, et en particulier tout ce qui a une fonctionalité complexe, la pyramide de pensée nécessaire au full-OO, la maîtrise des concepts inhérents, et la complexité/longueur du code nécessaire, en termes de lignes de code, de nombre de fichiers, de maintenance, ne joue pas en faveur du full-OO..

Et même pour des projets avec forte influence de l'IHM, personne n'est surpris de voir un package de SDK Java contenant plus de 40 000 fichiers ????? facile la maintenance

Bref, comme il était dit plus haut, chacun a ses avantages et ses inconvénients, et toute position dogmatique, et surtout universelle, relève plus de la religion que de la réalité professionnelle..

[arkhamon]

Envoyé par souviron34

Bref, comme il était dit plus haut, chacun a ses avantages et ses inconvénients, et toute position dogmatique, et surtout universelle, relève plus de la religion que de la réalité professionnelle..

Tout à fait d'accord, avec néanmoins une nuance : la religion c'est sacré (toute blague mise à part). Nous sommes ici dans ce que construit l'homme.
Mais tu as tout à fait raison. J'utilise la POO dans la conception des IHM, parce que déjà c'est plus simple et surtout dans certains cas pas possible de faire autrement. Après, pour al logique du programme (la partie "invisible"), l'utilsiation de la POO ne me semble pas toujours indispensable. On peut faire "pour la beauté du geste", "en cas d'école", "propre" sans pour autant abandonner la bonne vieille programmation structurée, qui elle a fait ses preuves.
LA POO est utile dans certains cas, simple dans d'autres, et inadaptée (j'entends par là pas forcément la solution la plus simple) dans d'autres. Elle n'en reste pas moins qu'elle est UN des outils disponibles, et qu'il serait idiot de vouloir l'imposer partout.

[souviron34]

Envoyé par arkhamon

avec néanmoins une nuance : la religion c'est sacré (toute blague mise à part). Nous sommes ici dans ce que construit l'homme.

Je voulais mettre "croyance" mais ça ne me semblait pas assez fort pour décrire

[Nemek]

J'ai lu les posts en diagonales et je ne comprends pas le sens de se "battre" autour de "procedural vs objet"... C'est simplement une affaire de goût quand on a le choix et de logique d'utilisation et de "présentation" (au niveau du source).

Que je fasse (pseudo langage inside):

Code :

1
2
3
4
5
6
function int bar(int a, int b) {
  return a+b;
}
main {
  print( bar(1, 2) );
}

ou

Code :

1
2
3
4
5
6
7
8
9
10
11
12
struct Foo {
  int a, b;
}
function int bar(Foo foo) {
  return foo.a + foo.b;
}
main {
  Foo foo;
  foo.a=1;
  foo.b=2;
  print( foo );
}

ou

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct Foo {
  int a, b;
  function* int(Foo) bar;
}
function int bar(Foo foo) {
  return foo.a + foo.b;
}
main {
  Foo foo;
  foo.a=1;
  foo.b=2;
  foo.bar=&bar;
  print( foo.bar(foo) );
}

ou

Code :

1
2
3
4
5
6
7
8
9
10
11
12
class Foo {
  int a,b;
  function int bar() {
    return a+b;
  }
}
main {
  Foo foo;
  foo.a=1;
  foo.b=2;
  print ( foo.bar() );
}

Par rapport au post initial, je trouve personnellement très élégant de mixer les langages/technologies pour répondre au mieux au besoin. Typiquement le cas des 1500 commandes à mettre à jour. Je peux soit le faire en SQL (ou OQL/HQL/LinQ/...) ou en pure "Java" mais il y en a clairement un qui sera plus optimal que l'autre. De même si pour une raison ou une autre, j'ai déjà chargé les 1500 commandes alors il pourrait être débile de le faire en pure-SQL (mode ensembliste) alors que j'ai déjà tous et uniquement les éléments qui m’intéressent.

De mon point de vue, l'antipattern c'est de se fermer aux solutions les plus simples, efficaces et élégantes.

[souviron34]

Envoyé par Nemek

De mon point de vue, l'antipattern c'est de se fermer aux solutions les plus simples, efficaces et élégantes.

tout à fait, ce qui m'avait fait un peu réagir sur le post de OneEyeJack..

Comme tu le dis dans l'autre discussion (post 1852) (Wouahahaha 1852 posts sur une discussion technique !!)

Les développeurs Java admettent de plus en plus qu'ils ne savent pas de quoi demain sera fait. Et que de toutes façons, quand l'heure viendra de faire quelque chose de générique, il faudra développer de toutes façons alors autant adapté convenablement à l'instant le plus approprié, c'est-à-dire quand ca se présente.

Mais c'est bizarre cette intransigeance et certitude de détenir la Vérité qu'il y a eu avec la mode OO..

(le "politiquement correct" adapté/appliqué à l'info ??)

[Nemek]

Envoyé par souviron34

tout à fait, ce qui m'avait fait un peu réagir sur le post de OneEyeJack..

Comme tu le dis dans l'autre discussion (post 1852) (Wouahahaha 1852 posts sur une discussion technique !!)




Mais c'est bizarre cette intransigeance et certitude de détenir la Vérité qu'il y a eu avec la mode OO..

(le "politiquement correct" adapté/appliqué à l'info ??)

Je pense que le problème vient de la formation et de la banalisation de l' "ingénerie logicielle". Quand je dis à mes collègues de KISS, leur réponse c'est souvent "Ah oui pas bête, j'y avais pas pensé" ...
En gros on leur a montré un bel échaffaudage et ils le reconstruisent à chaque chantier sans se demander si l'escabeau ne suffit pas.
Donc le problème c'est qu'ils prennent pas vraiment le temps de réfléchir mais on a pas vraiment pris le temps de les former "à penser autrement" ...
Ca me fait penser aux meilleurs TDs auxquels j'ai participé à la fac, c'était justement sur la COO. Et il n'y avait jamais de mauvaises solutions mais que de mauvais compromis ... Le prof était très ouvert et discutait chaque point et s'il n'avait rien à redire, ils disaient simplement "Ca le fait aussi".

[chaplin]

Souviron34:

Pour reprendre un exemple que j'ai déjà cité dans un autre débat, il ne vient à l'idée de personne de penser qu'une lettre "possède" une méthode "se poster"..

EyesOneJack:

En ce qui concerne l'enveloppe (et non la lettre) et sa capacité à se poster...

Qui décide de ce qu'un objet peut faire ou ne pas faire ? son concepteur

La principale difficulté en objet, c'est la conception, il suffit de voir la divergence de vue, "lettre" et "enveloppe"; dans le domaine informatique, ce qui s'en rapprocherait le plus c'est la notion d'email, alors quelle est la meilleure conception?

Réponse de Nemek:

Ca me fait penser aux meilleurs TDs auxquels j'ai participé à la fac, c'était justement sur la COO. Et il n'y avait jamais de mauvaises solutions mais que de mauvais compromis ... Le prof était très ouvert et discutait chaque point et s'il n'avait rien à redire, ils disaient simplement "Ca le fait aussi".

[souviron34]

Envoyé par chaplin

Souviron34:

EyesOneJack:


La principale difficulté en objet, c'est la conception, il suffit de voir la divergence de vue, "lettre" et "enveloppe"; dans le domaine informatique, ce qui s'en rapprocherait le plus c'est la notion d'email, alors quelle est la meilleure conception?

Réponse de Nemek:

tout à fait d'accord...

Je n'ai pas réfuté l'argument enveloppe vs lettre parce que pour moi c'est du pareil au même..

Mais c'est bien pour ça que l'idée même de dire "c'est comme ça et c'est tout" "c'est plus simple et plus maintenable" etc etc est absurde.. Cela dépend à quoi et comment on a été formé, mais la "logique" n'est pas absolue...

Pour tous les gens comme moi (et j'ai déjà cité de nombreuses fois le post qui explicitait totalement la différence (voir lien plus bas)) une vue fonctionnelle, c'est à dire où la fonctionalité prime sur ce qui est manipulé, est totalement compréhensible, alors qu'une vue "objet" où chaque objet fait sa fonctionalité est absurde..

C'est en ça que je disais que son exemple des reconnaissances de forme était absurde : PhotoShop, qui possède pourtant bien ce genre de traitements, comme la plupart des outils équivalents, a majoritairement été développé en termes de "fonctionalité", et non d'objets. Ce qui n'a pas empêché de modéliser un "objet" image... Et c'est en ça que la vision étroite OO est ça : étroite.. La COO existe depuis très longtemps et a été appliquée dans la plupart des gros projets procéduraux... C'est la syntaxe et l'absolutisme OO pur (héritage, polymorphise, surcharge, méthodes de classe ou d'objet) qui n'a pas été appliqué.

Mais cette différence n'implique pas une différence d'analyse, sauf dans l'esprit de gens purement formés à "un langage comme C++ résout tout"....

Je re-re-re-citerais le lien déjà donné post 32, en en particilier le second lien (le vrai post de référence) cité dans ce post...



Et, comme on l'a dit plus haut, toi, moi et d'autres, il n'est absoluent pas dit qu'une structure OO soit plus simple et directe qu'une structure procédurale.. ça dépend...

[chaplin]

Envoyé par souviron34

tout à fait d'accord...

Je n'ai pas réfuté l'argument enveloppe vs lettre parce que pour moi c'est du pareil au même..

Mais c'est bien pour ça que l'idée même de dire "c'est comme ça et c'est tout" "c'est plus simple et plus maintenable" etc etc est absurde.. Cela dépend à quoi et comment on a été formé, mais la "logique" n'est pas absolue...

Toute la difficulté en objet, c'est qu'il n'y a pas à priori d'approche logique pour concevoir, pire encore, quel est le niveau d'abstraction qu'on veut définir? C'est le début des emmerdes!
J'ai pas l'impression qu'en procédural, on se pose autant de questions existentielles.

[souviron34]

Envoyé par chaplin

Toute la difficulté en objet, c'est qu'il n'y a pas à priori d'approche logique pour concevoir, pire encore, quel est le niveau d'abstraction qu'on veut définir? C'est le début des emmerdes!
J'ai pas l'impression qu'en procédural, on se pose autant de questions existentielles.

Il peut y avoir des prises de tête sur la conception des "objets"..

Mais l'essentiel repose sur l'analyse et le flux de la fonctionalité...


C'est donc en général une arborescence logique assez simple, si on a un CdC assez précis.

Une première ébauche consiste à créer directement l'aborescence, en suivant un découpage par modules qui soit soit style SADT (en gros par niveaux de profondeurs d'appel), soit par fonctionalités.

Cette arborescence se retrouve normalement au niveau des répertoires, pour le gros, puis sur les noms des modules pour le niveau plus fin.

Et en ça, la logique est facilement compréhensible par quelqu'un qui rentre dedans... Classée par fonctionalité, si les noms de répertoires et de fichiers sont clairs, c'est assez simple et tout le monde a en gros la même logique...


Si on reprend un truc du style PhotoShop, tu auras en gros

Code :

1
2
3
4
5
6
7
8
9
10
11
lecture/écriture
     formats
traitements
     lissages
        1
         ...
     débruitage
        ..
outils
     palette
     ....

ce n'est sans doute pas ça, hein, mais c'est le style..

Il suffit de regarder beaucoup de packages du style libtiff, libjpeg, mepg_encoder, pour les plus simples, etc etc..

[OneEyedJack]

Envoyé par souviron34

Donc selon toi un développeur "mûr" va forcément évoluer vers le OO ??

Je ris....

Ben, oui... il y a de quoi rire, surtout parce que la conclusion à laquelle tu arrives n'a rien a voir avec ce que j'ai dit. Je connais d'excellents développeurs C et assembleur qui se fichent de l'OO et je ne chercherai certainement pas à leur dire de changer. Certaines personnes acquièrent de la maturité dans le procédural (tu es certainement très mûr de ce point de vue là et c'est très bien comme çà) et d'autres en acquièrent dans l'OO (cela ne peut pas être que mal).

Envoyé par souviron34

Quant aux billevesées sur "la maîtrise de la complexité passe par le polymorphisme"

Oui, je reconnais que j'ai fait un raccourci rapide. J'aurais du dire : "la maîtrise de la complexité passe par l'abstraction" (dixit la théorie des systèmes). Si tu as une meilleure façon, n'hésite pas à la communiquer. Il se trouve que dans l'état actuel des technos et des langages, l'abstraction passe essentiellement par le polymorphisme, les interfaces (au sens large, pas uniquement les interfaces Java), etc... Là aussi, si tu as mieux, n'hésite pas à communiquer sur le sujet. Mais peut-être n'a-t-on pas la même définition de ce qu'est la complexité ce qui pourrait expliquer une incompréhension mutuelle et une divergence de point de vue.

Envoyé par souviron34

Tes exemples sur Android sont simplement dûs au fait que la majorité des gens maintenant - ici - a un smartphone.. Mais dans les années 80 et 90 cela se faisait aussi, avec ce qui à l'époque s'appelait des "pagets" ou "pager", et mais leur utilisation était restreinte aux gens en ayant réellement besoin...

Je n'ai jamais prétendu que les téléphones portables sont les premiers objets créés de la main de l'homme à ne pas être inertes (mais je vois que ta liste n'est pas exhaustive, tu as oublié de mentionner le Tatoo (ok, là je te taquine un peu)).

Mes exemples visaient essentiellement à montrer que contrairement à ce que tu affirmes (opinion), il existe des objets actifs et capables de réactions à leur environnement (fait) mais visiblement, il semble que ce sont des "exemples orientés et basés sur des conceptions fausses" (opinion)...

Envoyé par souviron34

Bref, tes arguments pourraient être intéressants si ils n'étaient pas aussi orientés et basés sur des conceptions fausses (en particulier par rapport à l'historique)

Marrant, je ne pense pas avoir fait référence à un quelconque historique. Tu parles de "conceptions fausses", je ne me permettrais pas de porter un tel jugement de valeur sur les conceptions de quelqu'un et en particulier des tiennes.

Les tiennes sont visiblement les meilleures du monde et j'ai l'impression que le simple fait de dire que l'on peut considérer l'éventuelle possibilité d'imaginer qu'un objet peut être pensé comme non-inerte fait surgir de toi un intégrisme dont tu me qualifies. Accepte mes plus plates excuses si ce n'est pas le cas (je le dis sans ironie aucune)

J'ai plutôt tendance à considérer qu'il y a des conceptions qui ont des avantages qu'on essaie de maximiser et des inconvénients qu'on essaie de minimiser. Bien sur, dysfonctionnements et mauvaises performances sont de sérieux inconvénients. Pour juger de la solidité d'une conception j'ai pour habitude de tenir compte du contexte humain, technique et fonctionnel.


Initialement, Skip démarre la discussion sur le modèle anémique de Martin Fowler et du fait que ce dernier considère ce genre de modèle comme un anti-pattern, il justifie d'ailleurs ce point de vue avec de vrais arguments. Skip disait croire que l'OO est un mythe et que tout comme tu l'affirmes, "les objets sont inertes" et il demandait sur ce point l'avis de la communauté.

Ma réponse est : non, ce n'est pas un mythe.
Ma réponse n'étais pas : il faut absolument faire des modèles non-anémiques, tous les autres modèles sont à jeter aux orties et pour devenir un bon développeur il faut faire de l'OO. C'est d'ailleurs marrant parce que j'ai l'impression (mais je me trompe peut-être) que tu serais plutôt d'accord avec l'inverse : il faut absolument faire des modèles anémiques, tous les autres modèles sont à jeter aux orties et pour devenir un bon développeur il ne faut pas faire de l'OO.

Ma position sur le sujet n'est pas une opinion de ma part, c'est un fait : j'ai mis en place avec succès de tels systèmes. Je ne faisais que donner quelques exemples pour étayer mes propos et certainement pas pour convaincre quiconque que ce qu'il fait est bien ou pas. Changer la façon de penser de quelqu'un est long, difficile et douloureux et je ne m'essaie à l'exercice que lorsque la situation l'exige et que je peux m'appuyer sur des relais efficaces.

Mon objectif n'était pas de déclarer un guerre procédural vs OO qui n'a pas de sens. C'est une question de conception qu'elle soit procédurale ou non (oui, la conception n'est pas l’apanage de l'OO, tout ce qui se crée, se conçoit). Chacun applique les schémas de pensées qu'il juge pertinents qu'ils soient procéduraux, objets, fonctionnels, multi-agents ou autre (procédural et fonctionnel ne sont pas synonymes). Et la programmation structurée s'applique à tout ces paradigmes.

Peace

[OneEyedJack]

Envoyé par rimram31

Un exemple tout bête, si on suivait a la lettre l'OO, un pattern comme un MVC serait une aberration et en poussant le bouchon plus loin, il faudrait n'utiliser que du polymorphisme en lieu et place des délégations.

En ce qui concerne le MVC, il a été introduit dans Smalltalk fin des années 70.

Le MVC est plus un style architectural qu'un design pattern. En fait, selon les implémentations il comprend potentiellement plusieurs design patterns (Observer, Strategy, Decorator,...). Et, je te l'accorde, il est des implémentation malheureuses du MVC.

Le M, le V et le C représentent 3 types d'objets qui collaborent pour atteindre un objectif : permettre à un utilisateur d'avoir une perspective particulière sur un système et d'interagir avec ce dernier.

Ces objets font plutôt bien leur boulot et considérer que ce n'est pas de l'objet... J'avoue ne pas comprendre pourquoi c'est une aberration du point de vue OO, ils sont fortement cohérents, faiblement couplés et respectent le principe d'ouverture/fermeture...

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 ?

[souviron34]

Alors si ta pensée est celle-ci :

Envoyé par OneEyedJack

J'ai plutôt tendance à considérer qu'il y a des conceptions qui ont des avantages qu'on essaie de maximiser et des inconvénients qu'on essaie de minimiser. Bien sur, dysfonctionnements et mauvaises performances sont de sérieux inconvénients. Pour juger de la solidité d'une conception j'ai pour habitude de tenir compte du contexte humain, technique et fonctionnel.
...
Mon objectif n'était pas de déclarer un guerre procédural vs OO qui n'a pas de sens. C'est une question de conception qu'elle soit procédurale ou non (oui, la conception n'est pas l’apanage de l'OO, tout ce qui se crée, se conçoit). Chacun applique les schémas de pensées qu'il juge pertinents qu'ils soient procéduraux, objets, fonctionnels, multi-agents ou autre (procédural et fonctionnel ne sont pas synonymes). Et la programmation structurée s'applique à tout ces paradigmes.

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


Maintenant, en ce qui concerne :

Envoyé par OneEyedJack

Initialement, Skip démarre la discussion sur le modèle anémique de Martin Fowler et du fait que ce dernier considère ce genre de modèle comme un anti-pattern, il justifie d'ailleurs ce point de vue avec de vrais arguments. Skip disait croire que l'OO est un mythe et que tout comme tu l'affirmes, "les objets sont inertes" et il demandait sur ce point l'avis de la communauté.

Ma réponse est : non, ce n'est pas un mythe.

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).

ç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). ça n'est qu'un outil, et on en a fait une philosophie... Là est tout le problème....

Envoyé par OneEyedJack

Ma position sur le sujet n'est pas une opinion de ma part, c'est un fait : j'ai mis en place avec succès de tels systèmes.

moi aussi, et en procédural...

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

Certains pojets 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..

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


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)

[OneEyedJack]

Envoyé par el_slapper

Mouhahahahaha!!!!!

Bon, alors maintenant, tu vas expliquer à ma MOA bancaire pourquoi quand elle demande à développer un batch, nos chiffrages COBOL(qui incluent les chiantissimes transferts de fichier UNIX vers MVS et vice-versa) sont moitié moins couteux que les chiffrages Java-OO tout le toutim.

Indice 1 : en transactionnel, ça n'est sans doute pas vrai(mais je n'ai pas de billes pour vérifier)
Indice 2 : le temps de développement n'est sans doute pas le principal poids qui pèse sur les épaules des développeurs objet.

Ok. Tu as un numéro de téléphone à me communiquer ?

Blague à part, les batchs dont tu parles sont vraisemblablement des mécanismes d'intégration de systèmes ou de synchronisation. Et comme j'ai déjà eu l'occasion de le dire, ce n'est pas parce l'OO existe, qu'il faut jeter les autres technologies parce que c'est la mode (opinion), c'est plus moderne (opinion), etc...

L'intégration de système peut être un problème simple à régler dans certains cas et extrèmement compliqué dans d'autres. J'ai vu dans des banques/assurances

• des développements de batchs en COBOL lorsque les mappings inter-systèmes étaient simples
• des développements de batchs en Java à grands renforts d'automates à états et de moteur de règles parce qu'en COBOL c'était purement et simplement impossible dans un délai acceptable.

Cela dit, il existe tout un tas d'outils d'intégration écrits en Java (Apache Camel, Talend et autres) qui permettent de faciliter l'écriture de batchs. Dans le cas de Talend, on peut développer un batch sans écrire une ligne de Java. Il s'agit de sélectionner la source d'information (fichier, bdd, file JMS, etc) puis de sélectionner la destination (ficher, bdd, file JMS,etc) et de relier les champs de la source avec les champs de la destination. On peut appliquer tout un tas d'opérations (Splits, Joins, etc).

En fait ce genre d'outil met à disposition du développeur un DSL, un langage spécialisé dans le domaine de l'intégration de système (langage spécialisé par opposition à langage généraliste comme COBOL, Java, C, etc) dont voici un florilège fonctionnel (Apache Camel) : Aggregator, Claim Check, Competing Consumers, Dynamic Router, Load Balancer, Multicast, Publish Subscribe Channel, Scatter-Gather, Service Activator, Transactional Client, etc.

Que faut-il retenir de tout çà ?
Des fois, COBOL c'est bien, des fois, c'est pas bien
Des fois, Java c'est bien, des fois, c'est pas bien
Des fois, Java + Apache Camel c'est bien, des fois c'est pas bien
Comme disent les anglo-saxons : the right tool for the right job. Le bon outil est souvent lié à un contexte humano-technico-fonctionnel.

Envoyé par el_slapper

(1)l'encapsulation des données est particulièrement efficace quand il s'agit de données directement techniques(d'ou l'extrême efficacité pour tout ce qui est transactionnel à écrans complexes), et de données extrêmement standard qui s'encapsulent naturelllent dans des algorithmes compliqués.

Je ne suis pas sûr de comprendre, l'encapsulation, c'est la capacité à masquer ou rendre accessible des informations et des comportements (en Java çà passe par des public, private, protected)

Envoyé par el_slapper

(2)En bref, la puissance du polymorphisme s'applique là ou le polymorphisme s'intègre naturellement dans le problème(tautologie qui mérite plus de détails). Mes batches à moi n'ont rien de compliqué. Par contre, ils sont complexes : on a des milliers de petites opérations merdiques, dont les plus compliquées sont de l'ordre de la division, mais avec un enchevetrement de règles interdépendantes. Fonctionellement, tout dépend de tout. C'est pourquoi le modèle objet ou les données sont coupées les unes des autres est assez peu utilisable tel quel.

Dans de telles circonstances, çà vaut peut être le coup de jetter un oeil sur des moteurs de règles. Mais çà mériterait un post à part

Envoyé par el_slapper

(3)Ce qui coute cher à mes collègues de l'objet, c'est l'intégration. Par exemple, si ils ont besoin ne serait-ce que d'une seule donnée comptable, ils doivent se trimballer toutes les classes comptables, qui sont toutes plus ou moins interdépendantes. Moi, je vais me servir dans leur fichier, j'ai juste besoin de noter leur définition de données, je compile, et basta. J'en ai pour 5 minutes. Ils en ont pour des jours et des jours à gérer les adhérences.

Ben là, ce n'est plus un facteur de 1 à 2 comme tu disais précédement, plutôt de 1 à plusieurs centaines. Et encore une fois, si ta solution est simple, opérationnelle, performante, facile à maintenir, etc.. il n'y a pas de question métaphysique à se poser.

Envoyé par el_slapper

(4)Pour aller plus loin que le point 3, il me semble que nous, en procédural pur(la couche objet du cobol est désactivée dans nos standards de compilation), nous avons un magma informe de données, mais une séparation stricte des composants. Au pire, la compta change son format de données, fait une étude d'impact(20 minutes), envoie un mail aux applis concernée, et nous recompilons le jour de leur mise en prod(10 minutes par appli).

je n'ai qu'un mot à dire : tu as une solution très bien adaptée au contexte du problème. Pourquoi en changer si çà marche ?

Envoyé par el_slapper

En objet, il y a une séparation complète des données, au prix d'une dépendance beaucoup plus forte entre les composants. Ca a une qualité évidente : on ne touche pas aux données de la compta sans passer par le code de la compta. Mais aussi un défaut majeur : tout dépend de tout, donc tout le monde interagit avec tout le monde, donc la complexité du système augmente beaucoup plus avec sa taille qu'un bête procédural. Quand bien même je récupère 70% des données de la compta, ma restitution n'est que marginalement dépendante ce que qu'ils peuvent bien faire. Je ne passe jamais par leur code. Je n'ai besoin que du format de leurs données - et il ne change pas tous les 4 matins. Si je plante, c'est de MA faute(mon traitement est pourri), ou alors de LEUR faute(leurs données sont pourries), mais en aucun cas de la faute de l'intégration de leurs objets dans les miens, et autres problème s'intégration dans lesquels je vois mes voisins, tout aussi compétents que moi, se perdre

L'intégration/synchronisation de systèmes est une classe de problème vraiment à part comme je l'explique plus haut. Et çà vaut le coup de disposer d'outils spécialisés pour çà. Ne pas les utiliser, quelque soit le langage d'implémentation revient à écrire toutes les règles de mapping + toute la mécanique qui permet d'orchestrer et de déclencher les règles. Et çà peut être galère y compris pour des développeurs expérimentés et compétents.

Pour faire simple, l'intégration de système, c'est un peu comme deux personnes qui parlent les langues différentes et qui ne se comprennent pas, ils ont besoin d'un interprète qui fait la traduction. Le système A parle un langage (fichier source) que le système B ne comprend pas (fichier destination). Le traducteur, c'est le batch.

Dans les cas très complexes (sources multiples, récupération partielles, multicast de résultats partiellement fusionnés, etc...) Java peut ne pas être une solution optimale, au même titre que COBOL, C et autres langages généralistes.

Les liens que tu mentionnes posent la question du modèle anémique de Martin Fowler et non pas le problème de l'intégration de systèmes. Il est clair que si le problème est l'affichage à l'écran d'informations contenues dans une base sous la forme de listes, l'OO n'esp pas primordial et des frameworks comme Spring permettent de régler le problème facilement.

Imaginons maintenant que les informations en question représentent par exemple un planning avec des taches qui ont des durées, des dates de démarrage et des contraintes du genre : tel type d'activité ne peut pas précéder tel autre type d'activité sauf si tel condition est respecté, etc... Et que tu doivent représenter tout çà non pas dans un tableau mais plutôt dans un graphique ou chaque activité est reliée avec les activités précédentes et suivantes. l'utilisateur doit pouvoir réordonnancer le planning avec du drag&drop. Dans ce genre de cas, on peut envisager que chaque objet est responsable de son positionnement, maître de ces contraintes et est capable de projeter ses contraintes sur les autres objets. Un tel modèle objet sera plus pertinent et facile à implémenter.

Envoyé par el_slapper

L'encapsulation, au niveau fonctionnel bancaire, c'est juste un appel à se fracasser le crâne contre des problèmes qui n'ont pas lieu d'être. Il est bien plus simple de passer un simple paquet contenant les données utiles, et de coder ce qui va bien dessus. Ca a un défaut majeur, que j'ai cité au dessus : on maitrise moins qui travaille sur quoi. Mais vu que la principale difficulté est de trouver des cerveaux capables de gérér toute cette complexité, il me parait contre-productif de se trimballer des encapsulations dans tous les sens pour des modules purement fonctionnels.

Evidemment, si tu me parles de faire un bel écran avec de beaux boutons, mon argumentaire ne tien plus(et dans ce cadre, il m'arrive de faire des objets encapsulés). Mais je parle bel et bien du niveau fonctionnel, celui ou l'opération la plus compliquée(avec 3 exceptions en 12 ans), c'est une division.

c'est typiquement l'exemple que je cite ci-dessus.

[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 :

1
2
3
4
5
6
7
8
9
10
11
12
struct Foo {
  int a, b;
}
function int bar(Foo foo) {
  return foo.a + foo.b;
}
main {
  Foo foo;
  foo.a=1;
  foo.b=2;
  print( foo );
}

ou

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct Foo {
  int a, b;
  function* int(Foo) bar;
}
function int bar(Foo foo) {
  return foo.a + foo.b;
}
main {
  Foo foo;
  foo.a=1;
  foo.b=2;
  foo.bar=&bar;
  print( foo.bar(foo) );
}

ou

Code :

1
2
3
4
5
6
7
8
9
10
11
12
class Foo {
  int a,b;
  function int bar() {
    return a+b;
  }
}
main {
  Foo foo;
  foo.a=1;
  foo.b=2;
  print ( foo.bar() );
}

quand un simple

Code :

1
2
3
4
5
6
function int bar(int a, int b) {
  return a+b;
}
main {
  print( bar(1, 2) );
}

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...
QUOTE]

[souviron34]

Envoyé par arkhamon

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

[el_slapper]

Envoyé par OneEyedJack

(.../...)

On est beaucoup plus d'accord. Quand même une remarque sur ceci :

Envoyé par OneEyedJack

Imaginons maintenant que les informations en question représentent par exemple un planning avec des taches qui ont des durées, des dates de démarrage et des contraintes du genre : tel type d'activité ne peut pas précéder tel autre type d'activité sauf si tel condition est respecté, etc... Et que tu doivent représenter tout çà non pas dans un tableau mais plutôt dans un graphique ou chaque activité est reliée avec les activités précédentes et suivantes. l'utilisateur doit pouvoir réordonnancer le planning avec du drag&drop. Dans ce genre de cas, on peut envisager que chaque objet est responsable de son positionnement, maître de ces contraintes et est capable de projeter ses contraintes sur les autres objets. Un tel modèle objet sera plus pertinent et facile à implémenter.
(.../...)

J'ai justement dit que sur du transactionnel, je n'avais pas les billes pour juger. Typiquement, ça, c'est une transaction. L'utilisateur interagit avec un système complexe apparaissant à l'écran, et je manque de bouteille dans le domaine pour avoir une opinion pertinente.

Par contre, si on me demande d'extraire du planning qu'il aura sauvegardé des données, je sais que je préfèrerais me passer d'objets, extraire les données brutes dont j'ai besoin, et les triturer jusqu'à arriver à la forme demandée. Et je pense pouvoir prétendre être plutôt bon là-dedans.

[chaplin]

Quand on fait de l'objet, il y a un bagage nécessaire comme en mathématique. Cela suppose une formation solide.

Il faut d'abord définir les concepts avant de définir les classes, et déjà les concepts ne deviennent pas forcément des classes (difficulté majeure), ensuite on commence par définir les attributs de ces classes, ou alors on regroupe les attributs pour définir les classes, puis on cherche les méthodes.

Les frameworks, c'est super, mais le danger apparaît quand il faut trop s'adapter au framework, c'est à dire que celui-ci n'est finalement pas adapté au besoin, mais la paresse nous pousse à puiser dans la boîte à outil plutôt que de créer l'outil sur mesure.

Si on reprend l'exemple de la lettre à poster, quand elle est perdue, dans le langage objet on sera tenté d'écrire, elle s'est perdue, parce qu'on écrit tout au passif. Seulement, comment la lettre sait qu'elle est perdue, et si elle est perdue, c'est que logiquement l'objet est perdu, peut être même que la lettre est détruite. En informatique, on dira qu'on ne pointe plus sur l'objet, voir que l'objet est détruit, mais s'il est détruit, on ne peut pas savoir s'il est perdu, parce que l'information perdue est lié à l'objet qui n'existe plus .

J'ai fait un raisonnement par l'absurde, juste pour dire que le monde objet des programmes ne reflète pas la réalité. En revanche, on passe beaucoup de temps à la réflexion.

[_skip]

Envoyé par OneEyedJack

Imaginons maintenant que les informations en question représentent par exemple un planning avec des taches qui ont des durées, des dates de démarrage et des contraintes du genre : tel type d'activité ne peut pas précéder tel autre type d'activité sauf si tel condition est respecté, etc... Et que tu doivent représenter tout çà non pas dans un tableau mais plutôt dans un graphique ou chaque activité est reliée avec les activités précédentes et suivantes. l'utilisateur doit pouvoir réordonnancer le planning avec du drag&drop. Dans ce genre de cas, on peut envisager que chaque objet est responsable de son positionnement, maître de ces contraintes et est capable de projeter ses contraintes sur les autres objets. Un tel modèle objet sera plus pertinent et facile à implémenter.

c'est typiquement l'exemple que je cite ci-dessus.

L'exemple choisi est intéressant. Et typiquement pour ma part, je le représenterais très différemment selon que le planning est en mémoire, en mono utilisateur ou qu'il est basé sur une source de données, multi-utilisateurs.

Dans le premier cas, je me rapprocherais d'une modélisation tout OO, dans le 2e, probablement que je travaillerais avec des objets simples reflétant l'état actuel et que j'organiserais les déplacements comme des transactions indépendantes.