Discussion :

[blbird]

Bien répondu La.lune. Explicite et détaillé. Entièrement d'accord avec toi.

J'ai bien l'impression qu'on en arrive, avec la POO, à une technologie qui est rentrée dans les meurs comme un "standard", et qui maintenant subit les critiques des nouveaux développeurs qui trouvent que c'est trop complexe. J'avoue que ca me sidère, au vu de tout ce que la POO a apportée. Je serais curieux de voir par exemple l'IDE Eclipse (écrit en Java), avec ses capacités modulaires assez exceptionnelles, réécris dans un langage fonctionnel ou en pointeurs, sans polymorphisme et sans héritage. Je vous souhaite bien du courage.

La POO n'a pas été inventée pour simplifier le travail des décideurs.

Elle a été introduite pour répondre à 2 critères de qualité qui se sont révélés impératifs au fil de l'évolution de l'informatique :

• L'extensibilité est la facilité d'adaptation des produits logiciels aux changements de spécification
• La réutilisabilité est la capacité des éléments logiciels à servir à la construction de plusieurs applications

Ces 2 concepts définissent le terme de modularité des composants applicatifs. La POO a été créée pour répondre a ces critères, pas pour autre chose.

Après, que les concepts qui font tout l'avantage de la POO ne soient pas utilisés correctement, ce n'est clairement pas de la faute au langage. Ni même forcément au développeur, qui est obligé d'aller de plus en plus vite, sans pouvoir réfléchir plus loin que le besoin immédiat. Ce qui complexifie fortement la possibilité de rendre un code modulable, vu qu'il a pas de vision sur ce qui pourrait être demandé à moyen ou long terme.

La POO est une question de juste milieu entre faire quelque chose qui ne pourra jamais être réutilisé, et quelque chose de tellement abstrait que ca en devient lourd et incompréhensible. Mais ca, c'est le cas avec toutes les solutions informatiques à trouver...

[pcaboche]

Attention à ne pas confondre polymorphisme et héritage (par sous-typage) qui sont deux concepts séparés.

J'avais en tête un exemple avec de l'héritage et du polymorphisme et pour lequel pas mal de développeurs pondent des trucs assez bizarres. Mais je me suis dit qu'il y aurait forcément quelqu'un pour critiquer l'exemple plutôt que de chercher à comprendre ce qui pousse autant de développeurs à concevoir des trucs assez bizarres (proverbe Chinois : "Quand le sage montre la.lune..." ). Donc j'ai enlevé l'exemple.

J'aimerai bien savoir qui partage cette avis, parce quasiment tous les développeurs avec qui j'ai parlé ne conseil pas de commencer par la POO, avec parfois comme argument sa complexité justement.

Oui, je suis d'accord, il y a pas mal de concepts à assimiler avant.

Mais bon, ça vient quand même relativement rapidement dans le programme (parce que c'est très demandé en entreprise, et que de fait les étudiants sont aussi très demandeurs).

[MABROUKI]

C'est un vieux debat depuis la naissance de la POO...

Djiskra disait que cette idee ne pouvait naitre qu'en Californie....

Entendaient par là ,qu'elle vise comme le "Fordisme" à standardiser la production de code...pour la production en serie....

L'esprit americain ayant invente le "standard industriel",le "module"....
Tout le reste n'est que discussion de details pour developpeurs....

[moldavi]

Bonjour.

Enfin, Westfall évoque ce qui suit : « si une compagnie est suffisamment grande, ... »

Je crois que tout est dit ici. Le problème, ce ne sont pas les développeurs, ce sont les moyens, et encore.

En même temps je ne crois pas aux bibliothèques qui font le café. Chaque cas est particulier, et si une bibliothèque était capable de gérer tous les cas de figure avec les performances et la portabilité maximale, cela se saurait. Et on ne discuterait pas de cela ici.

Mais bon, responsabiliser le développeur qui travaille déjà 10 heures par jour, faut en vouloir. Le management n'a pas de limite visiblement.

[CodeurPlusPlus]

Je ne trouve pas qu'il est plus facile d'écrire du code réutilisable dans le paradigme impératif objet que dans le paradigme impératif procédural.

De toute façon, l'objet, on en reviendra bien un jour... c'était fait pour simplifier les choses et il se produit souvent tout le contraire. J'estime qu'il n'y a pas dix pourcents des problèmes qui sont plus faciles à résoudre en objet qu'en procédural ; aussi si plus de dix pourcents du code d'une application est "objet", c'est suspect.

Je trouve qu'on essaye souvent d'écrire du code réutilisable, qu'on se fait beaucoup ch... pour ça, et qu'en général on constate quelques années plus tard que cela n'a servi à rien. Soit le code n'est pas si réutilisable que prévu, soit on n'a pas besoin de le réutiliser.

Ecrire du code réellement réutilisable est une des taches les plus difficiles auxquelles un programmeur peut être confronté. Après de longues années d'expérience on commence à atteindre cet objectif relativement souvent (la définition de "souvent" dépendant sans doute de chacun). Mais c'est assurément quelque chose qu'aucune formation ne peut enseigner.

[TiranusKBX]

Tien moi aussi j'ai fait ma propre classe en PHP pour le traitement des base de données, un code que je réutilise tout le temps
et qui me fait gagner bien du temps avec un résultat bien plus modulable qu'avec pdo seul

Sinon pour la réutilisation de code il faut juste voir quels sont les parties que l'on à besoins de réutiliser souvent et l'on en fait des classe

[Cincinnatus]

Au niveau du code il sera toujours difficile de détecter les duplications : du code légérement diffférent peut faire la même chose (même si des outils comme checkstyle peuvent aider).

Les créateurs de Feature-Driven Development (FDD) ont mis l'accent sur la conception, le modèle.
En effet, au niveau de la modélisation la réutilisation est effectivement beaucoup plus aisée, la duplication plus claire et le code résultant plus propre.

[Gulien]

Pour moi la réutilisation de code existant doit être une priorité dans un projet.
Même si on ne code pas de but en blanc des choses très propres et très centralisées, on ne doit pas se laisser submerger, et on doit à un moment passer du temps à la mise en commun du code.

Il faut mettre en commun avant d'oublier ce que l'on a fait.

J'ai toujours considéré les différents projets où le code était mal classé, en doublon (et plus), pas documenté, comme carrément "Merdique" (excusez le langage).

Et je trouve ça complétement inacceptable de ne pas laisser aux employés le temps de faire de la documentation type Javadoc dès qu'on descends un peu dans les couches d'une appli.

Je suis un pu violent dans les propos, mais ce sujet me tient depuis toujours à coeur, et très peu d'entreprise se donnent les moyen de faire du vrai code objet, et pas simplement un enchaînement séquentiel/procedural d'objets, ce qui à mon sens ne sert pas à grand chose (un peu, mais pas à son plein potentiel).

[azias]

Comme pcaboche, pour moi la POO c'est surtout de l’encapsulation, moins la réutilisation qui est plutôt un concept de pratique de programmation en général.

Pour programmer de façon réutilisable je dirais que ça dépend surtout de la faculté à prévoir les utilisations futures. Il est assez simple de rendre une fonction ou une classe générique à outrance, elle n'en sera pas pour autant plus facilement (ré)utilisable. En revanche prévoir une forme qui sera facilement réutilisable dans des contextes variés nécessite, je pense, d'avoir une idée des contextes en question. Dans ces cas là, c'est surtout l'expérience du développeur qui va parler.

Une autre question plus problématique est celui de savoir ce qui existe, sinon aucune chance de le réutiliser. Dans le cadre d'un framework on sait ce qui existe en regardant et en cherchant dans la doc (si elle est mal faite on passe à côté de tout). Il faut bien reconnaître que la plupart du temps le code que nous écrivons est bien mal documenté. Et il nous manque une sorte de google pour le code pour nous dépêtrer de tout ça.

[Zefling]

Une autre question plus problématique est celui de savoir ce qui existe, sinon aucune chance de le réutiliser. Dans le cadre d'un framework on sait ce qui existe en regardant et en cherchant dans la doc (si elle est mal faite on passe à côté de tout). Il faut bien reconnaître que la plupart du temps le code que nous écrivons est bien mal documenté. Et il nous manque une sorte de google pour le code pour nous dépêtrer de tout ça.

C'est tout à fait vrai. Mais parfois le problème c'est que l'on cherche quelque-chose dont on ne connaît pas les noms. Ça m'est déjà arrivé de coder une fonction en PHP et me rendre compte 1 an après qu'elle existait en natif. Je n'avais juste pas chercher avec les bon thermes pour la trouver et comme il est difficile de tout connaître... Comme tu dis, l'expérience et une bonne doc joue pour beaucoup, on n'a pas la même approche sur un langage quand on débute ou quand on en fait depuis 10 ans.

[la.lune]

Comme pcaboche, pour moi la POO c'est surtout de l’encapsulation, moins la réutilisation qui est plutôt un concept de pratique de programmation en général.

Pourquoi ils ont réellement pensé à l’héritage et au polymorphisme qui sont des notions de base de la POO, tu penses que c'est juste pour faire beau à la sémantique de l'application? C'est une question de réutilisation qui a enfanté ce concept.

Quand on fait de l'héritage dans les class on s'assure au moins de ne pas avoir à dupliquer ni les déclarations des attributs en commun ni les méthodes pour toutes les classe filles. +1 en réutilisation.

Quand j'ai déjà une classe et qu'qu’après je me trouve avec le besoin de l'utiliser exactement mais que j'aurais aimé juste ajouter quelques attributs ou méthodes dont je l'étend c'est tout. Encore +1 en réutilisation.

Pour les interfaces c'est plutôt un contrat de typage et un contrat sur des comportements qu'on définit en pure virtuelle sans pour autant connaitre les classes cibles.

Ainsi on peut commencer à manipuler ces objets cibles dans des méthodes alors que leurs classes ne sont même pas encore définis, ceci juste à cause du contrat que définit l'interface et parfois on défini des interfaces vides juste le contrat de typage nous intéresse. Tous ces notions ont permis l'intégration des pattern et c'est ce concept qui a rendu la vie belle surtout aux concepteurs d'API,

Ceci a permis aussi de l'autre côté des API la mise à la portée du code source des interfaces et leurs signatures de méthode, et pourtant les vrai implémentations qui seront utilisés lors de l'exécution sont privés et compilées en code machine, et ça marche à cause du polymorphisme fourni avec la notion d'héritage en POO: tout ça +100 en réutilisation .

Ce concept d'interface montre le vrai sens même de l'abréviation d'API :Application Programming Interface

PS: Je ne dis pas qu'il n y a pas d'API sans POO mais je parle de l'avantage de la POO sur les API et qui donne un vrai sens au terme.

[foetus]

Pourquoi ils ont réellement pensé à l’héritage et au polymorphisme qui sont des notions de base de la POO, tu penses que c'est juste pour faire beau à la sémantique de l'application? C'est une question de réutilisation qui a enfanté ce concept.

Pas d'accord, et je confirme [dans un sens] les propos de pcaboche en première page:

La POO existe parce qu'il est plus facile de concevoir/ penser en terme d'objets que de traitements, surtout dans la "programmation moderne" (conception MVC, architecture avec des plug-ings, ..., si ce sont de bons exemples )
Après comme l'a dit DonQuiche [ou un autre intervenant], des fois ce n'est pas forcément vrai

Je pense pareil que olreak: la réutilisabilité ne peut se faire qu'avec de l'expérience et rester dans un même domaine.
J'ai travaillé dans une agence de communication et j'ai maintenu/ fait des jeux 2D, des applications connectées, des applications de réalité augmentée/ GPS, des applications de "performances" (avec des filtres) et c'est quasi impossible de faire du code réutilisable

Et justement, je dirais que la réutilisabilité passe aussi par les frameworks qu'on utilise. En fait, c'est plus "la colonne vertébrale" qu'on réutilise et qu'on adapte.

[la.lune]

Pas d'accord, et je confirme [dans un sens] les propos de pcaboche en première page:

La POO existe parce qu'il est plus facile de concevoir/ penser en terme d'objets que de traitements, surtout dans la "programmation moderne" (conception MVC, architecture avec des plug-ings, ..., si ce sont de bons exemples )

Je pense que tu n'as pas bien lu ce que j'ai écris ou que tu n'as pas compris l'objectif de mon message. Je n'ai nulle part nier ce que tu dis j'ai même parlé au début de l'avantage de la POO en matière de conception, toi tu me donnes l'exemple de MVC alors que ce n'est qu'un pattern parmis un très grand nombre de pattern.

Tu me parle d'architecture de plug-ings mais sur quoi est basé cet architecture, autre qu'un mélange de ce que je viens de citer y compris le concept d'API purement orienté POO.

Quand je parlais je n'ai pas réduit la POO en ce que j'ai dis mais j'ai bien posé la question que ce qui a engendré l’héritage? Si tu arrives à faire de bonnes conceptions et que tu utilises un des notions héritage, interface, polymorphisme, classe abstrait... c'est bien par ce que de la POO a été crée en partie pour t'offrir ça, sans lesquels tu aurais des conceptions très moches avec plusieurs duplications, toujours sur la base qu'on doit réutiliser ce qui est commun.

Et justement, je dirais que la ré-utilisabilité passe aussi par les frameworks qu'on utilise

De quoi on s'en sert pour concevoir de bon framwork, tu crois qu'on te fourni tout le code source du framwork pour aller le compiler toi même, où on te fourni une API à manipuler.

[DonQuiche]

C'est une question de réutilisation qui a enfanté ce concept.

Oui mais pas dans le sens que tu défends. Le contexte était celui de la programmation procédurale. Si tu voulais mille particules, il fallait un tableau pour chaque propriété des particules : xPositions, yPositions, zPositions, etc. Pour calculer la distance entre deux particules on avait donc : (xPositions[i] - xPositions[j])^2 + ... En gros les méthodes prenaient des indices en argument au lieu de prendre des objets.

En conséquence si tu avais n propriétés par particule, il fallait n tableaux. Comme passer n tableaux en argument est vite lourdingue, on déclarait ces tableaux en variables globales. Alors quand tu avais besoin de particules dans un autre fichier, tu copiais-collais tout ton fichier dans l'autre et tu risquais un conflit de nommage entre tes pelletées de tableaux d'un côté et des pelletées de tableaux de l'autre, surtout que "xPositions" c'est assez commun, comme tu t'en doutes. Dans un sens l'OOP échangeait un risque de conflit entre N noms de variables avec un risque de conflit entre K<N noms de types, ce qui améliorait grandement la situation.

L'autre grand bénéfice c'est que les langages OOP introduisaient naturellement une gestion dynamique de la mémoire : parce que même s'il était possible dans certains langages procéduraux de redimensionner des tableaux il fallait en pratique inclure cette logique dans chaque "constructeur" (la procédure qui te renvoyait l'index d'un nouvel élément). A chaque fois tester si la capacité était suffisante et, sinon, redimensionner tes N tableaux. En pratique c'était rare et on privilégiait des tableaux fixes dont la taille était manuellement ajustée lors du copier-coller.

C'est donc plutôt l'encapsulation et la gestion dynamique de la mémoire qui ont favorisé la réutilisabilité, et non le polymorphisme qui n'était que la cerise anecdotique sur le gâteau pour l'époque. A noter aussi que depuis les langages procéduraux se sont un peu améliorés.

[la.lune]

J'ai compris ce que tu veux dire mais là tu mélanges en partie entre encapsulation et héritage. Moi je ne suis pas entrain de parler de l'encapsulation, lui même à citer ça et je ne nie pas qu'elle offre aussi un gains en réutilisation, merci pour l'exemple.

Mais je voulais montrer plutôt l’intérêt de l'héritage qu'à la base c'est de réutiliser et éviter les duplications de ce qui est commun. Et bien sûr qu'il n y a pas d’héritage là où je ne peux pas encapsuler, car c'est basé sur les classe qui encapsule. Sinon ça n'a pas de sens du tout. Au fait la POO c'est un tout, mais chaque concept exerce son rôle. On ne peut réduire l’intérêt de la POO en matière de réutilisation à l'encapsulation

Bon pour ce qui est du polymorphisme c'est un outils qui a permis d'éviter des limites potentiel si l'héritage ne l'offrait pas, et tout ça au service de le réutilisation. Par exemple il ne faut pas que je sois bloqué lors d'une factorisation d'une méthode dans une classe mère si un besoin d'une implémentation spécifique d'une méthode donnée de la classe fille est nécessaire, ça fait partie de la force de la réutilisation et les autre exemples que j'ai donné.

[pcaboche]

Quand on fait de l'héritage dans les class on s'assure au moins de ne pas avoir à dupliquer ni les déclarations des attributs en commun ni les méthodes pour toutes les classe filles. +1 en réutilisation.

Justement, l'héritage/polymorphisme ont parfois un effet pervers.


Par exemple, au lieu de chercher les aspects communs qui existent entre plusieurs concepts (pas forcément apparentés d'ailleurs) afin de minimiser le nombre de classes nécessaires à la mise en oeuvre d'un programme, on a tendance à chercher les différences et à sous-classer à outrance...


Le polymorphisme peut même mener à des raisonnements assez bizarres, du genre : (j'ai une classe -> elle a certaines propriétés qui m'intéressent -> je fais une sous-classe au nom de la "réutilisabilité", même si conceptuellement la sous-classe n'a pas grand chose à voir avec sa classe parente).



Donc l'héritage/polymorphisme, ce n'est pas ce qui contribue le plus à la réutilisabilité du code...






Le plus souvent, ce que l'on cherche à réutiliser, ce sont les algorithmes.
Pour ce faire, on voit de plus en plus la chose suivante en POO :


On définit une méthode qui:
- prend en argument une structure de données (ex: un objet)
- prend en deuxième argument une "fonction" (délégué / lambda /...) qui va extraire les propriétés de l'objet qui nous intéressent
- dans le corps de la méthode, on définit l'algorithme qui va travailler sur ces propriétés


De cette façon, on peut développer des algorithmes applicables sur des classes qui n'ont strictement rien à voir entre elles (pas de classe ou d'interface commune entre elles).


Le seul principe de POO en oeuvre ici, c'est l'encapsulation (on n'utlise ni l'héritage, ni le polymorphisme).

Et oui, cette technique est héritée directement de la programmation fonctionnelle (fonction d'ordre supérieur) et commence à gagner en popularité (ex: omniprésente dans Linq).

[Luckyluke34]

Quand je parlais je n'ai pas réduit la POO en ce que j'ai dis mais j'ai bien posé la question que ce qui a engendré l’héritage? Si tu arrives à faire de bonnes conceptions et que tu utilises un des notions héritage, interface, polymorphisme, classe abstrait... c'est bien par ce que de la POO a été crée en partie pour t'offrir ça, sans lesquels tu aurais des conceptions très moches avec plusieurs duplications, toujours sur la base qu'on doit réutiliser ce qui est commun.

Le polymorphisme peut même mener à des raisonnements assez bizarres, du genre : (j'ai une classe -> elle a certaines propriétés qui m'intéressent -> je fais une sous-classe au nom de la "réutilisabilité", même si conceptuellement la sous-classe n'a pas grand chose à voir avec sa classe parente).

Attention à ne pas confondre polymorphisme et héritage (par sous-typage) qui sont deux concepts séparés.

Le polymorphisme, c'est la faculté d'une instance d'une classe dérivée de pouvoir être passée et utilisée partout où on attend une instance de la classe de base.

• Il peut y avoir polymorphisme sans réutilisation. Ex : tous les éléments hérités d'une classe de base sont surchargés dans la classe dérivée.
• Il peut y avoir réutilisation par héritage sans qu'il soit question de polymorphisme où que ce soit dans le programme, c'est à dire sans qu'on ne passe (ou retourne) une instance de la classe dérivée D là où une instance de la classe de base B est attendue.

[jnspunk]

Pourquoi les développeurs ne réutilisent pas le code existant ?
- Le chef de projet n'informe pas les développeurs du code existant, car lui même l'ignore ou connait mal les technologies utilisées.
- Les développeurs ne peuvent pas exploiter le code existant à cause des dépendances, librairies, accès refusé, etc...
- La conception du code ne prenait pas en compte sa réutilisation.

Pourquoi les développeurs ne codent pas de manière à réutiliser le code ?
- Le directeur technique demande à un développeur(et payé comme tel) le travail d'un concepteur,
ignorant la conception le développeur donne le "travail" aux autres développeurs,
puis dans l'équipe qui prend en compte la réutilisation du code?
- Le chef de projet donne au compte goutte les informations aux développeurs et le code ne peut se réutiliser lorsqu'on le conçoit sans vues d'ensemble.
- Quand le Chef de projet utilise le travail des développeurs comme brouillon puis changent du jour au lendemain les cas d'usages à développer, la volonté de réutilisation du code en pâti.

Un bon séjour en SSII française lui ferait du bien.

[Cyrilange]

J'ai créé mon propre "Framework" dans lequel j'ai tous les codes que je réutilise. Sans parler des templates pour les interfaces que je réutilise également sous Visual Studio 2012. Donc je ne me sent pas concerné par cet article, même si il est toujours possible de faire mieux pour éviter la redondance.

[DonQuiche]

J'ai créé mon propre "Framework" dans lequel j'ai tous les codes que je réutilise. Sans parler des templates pour les interfaces que je réutilise également sous Visual Studio 2012. Donc je ne me sent pas concerné par cet article, même si il est toujours possible de faire mieux pour éviter la redondance.

La question n'est pas de savoir si la réutilisabilité est possible dans certains cas mais ce qui la limite dans les autres. Si tu ne te sens pas concerné c'est uniquement par manque d'expérience.