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