IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langages de programmation Discussion :

La réutilisation dans la POO et ses limitations actuelles


Sujet :

Langages de programmation

  1. #21
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    (.../...=Après je ne dis pas qu'il faut tout jeter pour faire de la programmation fonctionnelle, mais juste que de s'essayer à d'autres paradigmes permet de voir d'autres manières de penser. Même si on ne voit pas le bénéfice immédiat, ça a un effet positif sur notre manière d'appréhender certains problèmes (ex : la question de la réutilisabilité).
    ça n'est pas un concept nouveau
    Citation Envoyé par Eric S Raymond
    LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot. (You can get some beginning experience with LISP fairly easily by writing and modifying editing modes for the Emacs text editor, or Script-Fu plugins for the GIMP.)
    Je suis personellement en train de me mettre à Racket(un sous-sous-dialecte du LISP), et ça tord le cerveau, méchamment. J'ai comme un doute sur la lisibilité d'une appli finie pour qui ne l'a pas écrite, mais je commence à comprendre ou Eric Raymond veut en venir dans le paragraphe qu'il vient de citer. La réutilisation fait partie de l'ADN de ce langage. On ne peut rien faire sans penser réutilisabilité, ce qui accroit la puissance du langage d'autant.(mais je note qu'ils ont quand même des objets. Comme quoi, parfois, ça peut servir aussi).
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  2. #22
    Membre habitué
    Inscrit en
    Juillet 2007
    Messages
    67
    Détails du profil
    Informations forums :
    Inscription : Juillet 2007
    Messages : 67
    Points : 131
    Points
    131
    Par défaut
    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).

  3. #23
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    222
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 222
    Points : 766
    Points
    766
    Par défaut
    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.

  4. #24
    Expert confirmé Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    Avril 2007
    Messages
    1 168
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 168
    Points : 4 654
    Points
    4 654
    Par défaut
    Citation Envoyé par olreak Voir le message
    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.

  5. #25
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    545
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Directeur Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2010
    Messages : 545
    Points : 2 084
    Points
    2 084
    Par défaut
    Citation Envoyé par olreak Voir le message
    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.

  6. #26
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 627
    Points : 10 548
    Points
    10 548
    Par défaut
    Citation Envoyé par la.lune Voir le message
    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.

  7. #27
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    545
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Directeur Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2010
    Messages : 545
    Points : 2 084
    Points
    2 084
    Par défaut
    Citation Envoyé par foetus Voir le message
    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.

  8. #28
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par la.lune Voir le message
    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.

  9. #29
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    545
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Directeur Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2010
    Messages : 545
    Points : 2 084
    Points
    2 084
    Par défaut
    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é.

  10. #30
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par la.lune Voir le message
    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).
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  11. #31
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Citation Envoyé par la.lune Voir le message
    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.
    Citation Envoyé par pcaboche Voir le message
    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.

  12. #32
    Membre expert
    Avatar de MarieKisSlaJoue
    Homme Profil pro
    Ingénieur Cloud
    Inscrit en
    Mai 2012
    Messages
    1 145
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Roumanie

    Informations professionnelles :
    Activité : Ingénieur Cloud
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2012
    Messages : 1 145
    Points : 3 653
    Points
    3 653
    Billets dans le blog
    20
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    L
    Autre facteur non négligeable : ces concepts de classes semblent assez naturels et simples à appréhender (du moins au début...), donc que on s'est dit que ce serait plus facile de former de la main d'oeuvre dans ce domaine.
    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. Alors que je pense comme toi, la POO permet de parler de concept avec des gens qui ne connaisse pas la programmation car c'est plus simple de se représenter un objet Personne qui à un nom et qui peut marcher que juste des structures et des fonctions.
    Aimant les phases de conception (Peut être encore plus que le code) Je trouve un grand plaisir personnellement dans la POO et ses concepts. Avoir une couche d'abstraction possible avec l'encapsulation c'est vraiment quelque chose d'agréable je trouve.

    Après mon avis est forcément biaisé, vu que je n'ai travailler que très peu avec les langages fonctionnels.
    Ce post à été écrit par un panda
    Apollo 11 - AGC revue de code
    -- qwerty keybord

  13. #33
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    545
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Directeur Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2010
    Messages : 545
    Points : 2 084
    Points
    2 084
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    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
    Ce n'est pas le polymorphisme qui mène à un raisonnement bizarre, celui qui raisonne bizarrement qui tombe dans l'erreur. Si on t’apprend le principe de là liberté et tu commences à penser que "liberté" veut dire faire tout ce qu'on veut, et tu commences à faire tout ce que tu veux au nom de la "liberté" tu finira en taule, celui qui t'a apprit la liberté t'a appris aussi que ta liberté s’arrête là où commence celle des autres.

    Si quelqu'un ne sait pas s'en servir d'une technologie, c'est son problème à lui: concepteur, pas la technologie. On accuse pas par exemple un langage à cause des gens qui codent avec les pieds.

    Tout demande de l’intelligence et de l’ingénierie.

    Revenons dans ton exemple
    (j'ai une classe -> elle a certaines propriétés qui m'intéressent -> je fais une sous-classe au nom de la "réutilisable")...
    Ok le plus intelligent ne créera pas de sous classe banalement, mais je te pose la question, si après avoir fini avec ton programme et qu'un 2e jour tu te trouve sur l'obligation d'étendre ton programme ou tu as besoin de la même classe avec plusieurs méthodes et plusieurs lignes de code, mais tu veux étendre avec quelques modifications à apporter, va-tu tout casser? et possible même de crée des bug sur ce qui marchait (régression !!!) et duplication, et consommation en plus de la mémoire , ou tu va redéfinir ou définir juste les quelques méthodes que tu as besoin.

    Le problème se complexifie encore si tu dois créer plusieurs classes différentes qui ont toutes en commun l’ancienne classe quelle option tu optes: ((héritage/polymorphisme ) ou (copier/coller et tout casser après encore ))

    Et si encore après un certains temps tu veux étendre toutes tes classe là, avec une nouvelle fonctionnalité dans une nouvelle méthode et que dans tous les cas on doit ajouter du code aux classes pour ajouter la nouvelle méthode; Toi qui a des classes indépendantes tu va l'ajouter à chaque classe et recompiler tout . Moi je vais l'ajouter à la classe mère, la recompiler elle seule et tout marche nickel dans toutes les classes filles, bonne réutilisation.

    Et si j'ai des adaptations en fonction des implémentations spécifiques des classes filles, le polymorphisme me permet de cibler ces implémentations dans ma nouvelle méthode et tout va marcher sans que je touche aux classes filles.
    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).
    C'est ce qui fait que ton exemple tombe pile poile et montre aussi en quoi on a besoin de l'héritage et du polymorphisme: S'il faut une implémentation spécifique d'une méthode donnée utilisé dans l'algorithme et que l’implémentation spécifique permet des gains de performances sur l'algorithme, et que cette méthode dépend de la structure de chaque objet cible?

    Vas-tu faire quelque chose d'anti-pattern, et tester toujours sur le type d'objet cible et faire du switch sur toute la liste des types déjà existants, et dire si objet en paramètre est de tel type alors algorithme fait ceci... et si tu crées dans le future un nouveau type, donc pas possible d'utiliser le même algorithme de façon optimale que de le démonter et redéfinir encore un nouveau cas.

    Ou bien pour éviter tout ça, tu vas définir un algorithme unique dans une classe mère dans lequel une des méthodes utilisés dans l'algorithme sera définit séparément, pour la bien coder dans une implémentation spécifique de la classe cible et l'algorithme est polymorphe, lequel des options tu choisit?

    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)

    Ne mélange pas les choses. Déjà faire de la programmation fonctionnelle n'est pas synonyme de ces techniques de méthodes static. En C# certes on voit cette technique avec Linq, qui sont aussi embellis avec la notion de méthodes d’extension, mais ceci ben tout simplement par ce que les objets cibles possèdent en commun une interface et non une classe: c'est l'interface IEnumerable<T>, or en ne peut pas coder une méthode dans une interface en C#, donc on ne peut pas coder un algorithme dedans.

    Et pourtant on utilise l’héritage, car on applique tous les méthodes de Linq sur toutes les instances héritant de IEnumerable<T>. Mais cette technique n'est pas dépourvue d'une faiblesse vu qu'on peut pas faire du polymorphisme.

    Mais regarde un peu en Java lorsqu'ils ont voulus introduire la programmation fonctionnelle avec des fonctionnalités équivalentes à Linq, qui sont incluent dans l'API Stream de Java 8: certes les Iterable<E> ont tous en commun des interfaces, et l'interface Collection<E> qui en hérite est l'interface mère de toutes les Collection.

    Alors quand ils ont voulu ajouter la méthode qui ouvre un flux(Stream) sur la collection encours et appliquer des traitement récursifs et les algorithme de traitement fonctionnellement, et permettre aussi le traitement parallèle qui exploite le multi-coeur, tout ceci sans la moindre effort du développeur, ils ont plutôt pensés à étendre la notion d'interface, en ajoutant la possibilité de fournir une implémentation par défaut d'une méthode dans une interface, ainsi pour fournir du corps on doit ajouter le mot clé default dans la signature de la méthode.

    Du coups, avec cette technique ils ont enlevé la barrière qu'il faut une classe pour pouvoir définir un traitement(algorithme) sur tous les enfants.

    Par suite, ils ont ajouté deux méthodes à l'interface Collection<E> pour répondre, ainsi on a le code suivant dans l'API standard
    Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    default Stream<E> stream() {        
    return StreamSupport.stream(spliterator(), false); //false => isParallel()==false, donc séquentielle
        }
     
    default Stream<E> parallelStream() {
            return StreamSupport.stream(spliterator(), true); //true => isParallel()==true, donc un traitement parallèle
        }
    Et là j'ai tout ce qu'il faut pour n'importe quel type de collection qui sont nombreux, grâce à l'héritage, la liste est longue:
    Ainsi j'arrive facilement à faire ceci
    Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    ArrayList<Personne> personnes = new ArrayList<>();                         
    personnes.add( new Personne(....));
    //..........                            
                   personnes.stream()               
                            .filter(p->p.getAge()>=20)
                            .forEach(p->System.out.println("Nom : "+ p.getNom()));
    Ca va m'affiche les nom des personnes qui ont un age supérieur ou égale à 20.

    Je peux enchaîner plusieurs actions à la fois et Stream (une trentaine de méthodes existante) lui il n'évalue pas les expressions en appelant les méthodes là un après un sur tous les éléments, mais il fais de l'évaluation paresseuse, du coup c'est comme si on lui donne une seule demande et il les traite ensemble, du coup pas de duplication de donnés, il applique le traitement qu'en cas de nécessité.

    Quand il se positionne par exemple sur le premier élément de la liste, il applique tous les méthodes sur lui s'il est concerné et continue sur le 2e.... dans cet exemple on pas cette série : filtrer, filter, filter filter,.. et puis afficher, afficher,afficher,afficher... non, on a : filter, afficher(s'il est filtré), filter, afficher(s'il est filtré),filter, afficher(s'il est filtré) du coup de la programmation fonctionnelle par excellence

    Tout ça peut s'appliquer à tous les types de collection grâce à l'héritage.

  14. #34
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 627
    Points : 10 548
    Points
    10 548
    Par défaut
    Citation Envoyé par la.lune Voir le message
    Le problème se complexifie encore si tu dois créer plusieurs classes différentes qui ont toutes en commun l’ancienne classe quelle option tu optes: ((héritage/polymorphisme ) ou (copier/coller et tout casser après encore ))
    Tiens je te donne du grain à moudre parce que je suis gentil

    Tu oublies un truc qui est association/ agrégation/ composition.
    Parce que l'héritage ne représente que 5 à 10% de ce concept.

    Pourquoi tu ne crées pas un simple pointeur dans tes nouvelles classes, avec éventuellement de l'amitié

    Il y a des livres qui explique tout cela, et il y a des règles presque mécaniques, qui évite au concepteur de se faire un nœud au cerveau

    En te lisant tu ne sembles pas t'en rendre compte que l'héritage bouffe du CPU et de la mémoire

    Citation Envoyé par la.lune Voir le message
    Moi je vais l'ajouter à la classe mère, la recompiler elle seule et tout marche nickel dans toutes les classes filles, bonne réutilisation.
    Toi qui m'a repris sur les librairies, mais tu ne sais pas que des fois on ne peut pas toucher à la classe mère: on casse le contrat

  15. #35
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    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.


    Citation Envoyé par MarieKisSlaJoue Voir le message
    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).
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  16. #36
    Membre chevronné

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Février 2004
    Messages
    758
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : Février 2004
    Messages : 758
    Points : 2 086
    Points
    2 086
    Par défaut
    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...

  17. #37
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par blbird Voir le message
    (.../...)
    • 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
    (.../...)
    Mouarf. J'ai pratiqué avec assiduité la réutilisabilité, la modularisation, l'extensibilité en COBOL, langage procédural à la limite de la caricature.
    _extensibilité : j'ai implémenté 9 versions successives de la même specs en un seul samedi.
    _réutilisabilité : j'ai créé plein de modules appelables partout, d'autres ont fait pareil, et ils sont devenus standards...dès qu'assez de gens étaient au courant.

    la POO, franchement, c'est comme du COBOL...avec juste le code d'accès aux données qui est livré dans le même composant que la définition des données. Je détaille :
    En COBOL, on a des structures de données complexes. Un peu comme une classe qui aurait 100% de ses données publiques, sans getter-setter, juste du "Public maDonnee as Int64". Ca fait peur quand on est pas habitués. Le seul truc que la couche objet apporte(mais avec des conséquences massives), c'est des getters-setters personalisés(par exemple pour vérifier que MaDonnee est une puissance de deux, car c'est dans la spec. Ca, je ne peux pas faire en COBOL).

    Ca a des conséquences amusantes, mais pas sans défaut. C'est bien sur beaucoup plus puissant pour les données centralisées(typiquement, les contrôles sur un setter de valeur de compte bancaire sont assez musclés, et en Objet, ils sont de facto à un seul endroit. En procédural, il faut se farcir une conception qui le garantisse). Mais quand on commence à tourner assez loin des données centralisées, ça devient soudain assez chiant. Quand je bossais sur la synthèse bancaire(i.e. les tableaux de bords qui indiquent que l'agence de Villers-Cauterets a vendu 2 assurances-vie de plus que le mois dernier), on avait besoin de données qui étaient complètement destructurées par rapport aux besoins de nos amis comptables. Et de les triturer au delà de toute mesure pour donner des tableaux de bord acceptables.

    En objet, il aurait fallu faire de l'héritage multiple(un peu de compte, un peu de produit, un peu de structure d'agences, un peu de personnel), avec des surcharges de partout. Dédié. Au lieu de ça, on vide les bases, on remplit un fichier plat dans la définition de données qui nous plait bien, on la toutouille comme des déments(et suivant les specs, hein, on est pas des cowboys), et ça tourne du feu de Dieu. Ca a certes l'inconvénient de devoir refaire l'alimentation si la structuration comptable change(mais est-ce fréquent?), mais c'est bien le seul inconvénient.

    Résultat, quand on nous a demandé de refaire la chaine marketing en COBOL, et que j'ai demandé pourquoi ils ne le faisaient pas en JAVA(comme les données étaient sur la machine ou tournait JAVA, ça me paraissait futé de ne pas se farcir des FTP dans tous les sens), on m'a répondu "parceque les développements COBOL sont deux fois moins chers". Historique de chiffrages à l'appui. Et aussi parcequ'au niveau performances, il n'y avait pas photo non plus(mais bon, ça c'est moins la POO que la machine MVS, c'est assez enorme ce que ça peut avaler, ces bêtes-là). Si les développements en procédural sont deux fois plus rapide, peut-être qu'au final, dans ce contexte, la POO n'était pas la référence ultime en terme de réutilisabilité, de modularité, d'extensibilité???



    Eloignons-nous un peu de mon passé bancaire(qui est fatalement biaisé, comme toutes nos expériences) et reprenons de la hauteur. La POO est un outil dans la boite. Un outil superbe. Mais ça n'est pas le seul. Si Eric Raymond conseille d'apprendre des langages représentant différentes "approches"(lire : paradigmes), c'est justement pour ne pas se laisser aveugler par un seul outil. En fonction du problème posé, on choisira tel ou tel paradigme. L'objet est imbattable dans un certain nombre de domaines - ceux dont la structure extérieure peut changer souvent, mais la structure de base est immutable. Les interfaces sont souvent dans ce cas-là. Mais dans d'autres domaines, ou on doit sans cesse tordre les structures, ou alors ou on a un besoin desespéré de performances, alors il faut oublier.

    C'est pour ça que j'essaye de me mettre au fonctionnel(et j'en chie grave). Que je m'en serve ou non, ça fera de moi un meilleur programmeur. Parceque j'aurais une vision plus complète des outils présents dans la boite.

    Pour Eclipse : EMACS est écrit en LISP. Pas en POO. et il est bien vivant et utile. (bon, j'abuse d'Eric S. Raymond, en ce moment, dans mes citations - mais il est assez fort pour le mériter, et assez fier de lui pour l'apprécier).
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  18. #38
    Membre chevronné

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Février 2004
    Messages
    758
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : Février 2004
    Messages : 758
    Points : 2 086
    Points
    2 086
    Par défaut
    Il faut savoir utiliser les langages pour ce à quoi ils sont le plus efficace. On utilise pas un langage Objet pour "triturer" des données, ce n'est absolument pas adapté. On peut faire de la modularité dans beaucoup de langages qui ne sont pas POO. J'ai même déjà vu des notions de POO en Lotus Notes!!! L'affectation d'un objet à un autre en POO est juste une modification de pointeurs.

    Mais cela devient juste des usines à gaz parce que les langages n'y sont pas adaptés et n'ont pas été conçus pour ca.

    Mais pour faire de la modularité, clairement, la POO est de loin actuellement le concept le plus adapté. Même si, quelque soit le langage, rendre un code réutilisable est toujours plus long que de le faire rapidement juste pour soi.

    Et sinon je suis tout à fait d'accord qu'il faut connaître plusieurs paradigmes de langages, et que chaque langage a ses avantages et ses inconvénients. Mais dire que la POO est un inconvénient plus qu'un avantage, c'est tout simplement faux. D'ailleurs, pour moi, un développeur reste junior tant qu'il continue à croire qu'un seul langage parmi ceux qu'il connaît est le meilleur, sait tout faire et que les autres ne servent à rien.

  19. #39
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    545
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Directeur Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2010
    Messages : 545
    Points : 2 084
    Points
    2 084
    Par défaut
    Citation Envoyé par foetus Voir le message
    Tu oublies un truc qui est association/ agrégation/ composition.
    Parce que l'héritage ne représente que 5 à 10% de ce concept.

    Pourquoi tu ne crées pas un simple pointeur dans tes nouvelles classes, avec éventuellement de l'amitié
    On dirait qu'on ne lit pas ce que j'écris, premièrement je suis entrain de réfuter celui qui accuse l'héritage et je lui montre un exemple de la réutilisation sans pour autant dire que c'est la seule solution en POO. Où est ce que j'ai dis que c'est le seul cas.

    En 2e lieu, depuis mon premier message j'ai souligné l'importance des desing-pattern, qui regroupent l'ensemble concepts objets pour offrir des conceptions de qualités et tout ce que tu dis (association/ agrégation/ composition) sont bien utilisés en détail, on est pas là pour faire un cours de design-pttern.

    Mais aller jusqu'à dire que
    l'héritage ne représente que 5 à 10% de ce concept, c'est passer à côté de la plaque, non seulement tu mélanges entre les model de conception des structures de données et techniques propres au codage pour la réutilisabilité, mais tu mélanges aussi entre techniques de conceptions basés sur les pattern et concepts de base de la POO.

    L'héritage est à la fois un pattern et un concept de base de la POO comme l’agrégation, les pattern sont un mélange de tous les concepts de base, et le cas le plus général on ne pressente pas un pattern avec un seul principe de base.
    En te lisant tu ne sembles pas t'en rendre compte que l'héritage bouffe du CPU et de la mémoire

    Encore un passage à côté de la plaque et des propos totalement insensés

    Tu veux me dire que l’extension par association/ agrégation consomme moins de moire et moins de temps CPU que l’extension par héritage

    Il faut définir déjà cette extension si tu veux me dire que l'état(le contenu des attributs) de l'étendu est toujours unique pour plusieurs objets qui étendent, dans ce cas ce n'est même pas une relation d'héritage mais de ManyToOne, OneToMany(un à plusieurs) donc il faut plutôt de association/ agrégation et je ne vois pas le malade qui allait faire de l'héritage dedans et pourquoi dupliquer l'état de l'objet alors qu'un seul nous suffit. On a une seule référence/pointeur à passer aux autres.

    Mais si tu veux me dire que l'état de l'étendu est toujours propre pour chaque objet qui étend et tu veux me dire que
    association/agrégation est mieux en consommation de mémoire et du CPU , vraiment vraiment là c'est du n'importe quoi ce que tu avances

    Mais comment oser dire ça alors que sur le tas on a deux objets à chaque création d'un objet, c'est deux objets en double par rapport à l'héritage qu'on aurait un seul, même si les contenus sont identiques en état, ce qui fait que l'
    association/agrégation contribue à une perte de mémoire et du temps CPU.

    Voici une preuve pour illustrer ce que je dis, tu pourras le prendre et le coder d'un autre langage, le principe est simple, c'est juste deux classes dont on étend par agrégation et par héritage, sans changer quoi que se soit et après créer 5millions d'instances dans main pour voir lequel consomme le plus, et lequel est plus rapide, je les crée et les met dans une liste c'est tout:

    Code de la classe mère :
    Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    class MClass{
    protected long a; 
        public MClass(long a) {
            this.a = a;
        }
    public long getA() {
            return a;
        }
    public void setA(long a) {
            this.a = a;
        }
     
       }

    Classe Extension par héritage
    Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    class ExtMClass extends MClass{ 
         long c;
     
        public ExtMClass(long a, long c) {
            super(a);
            this.c=c;
        }
    public long getC() {
            return c;
        }
    public void setC(int c) {
            this.c = c;
        }
    public void affiche(){
           System.out.println("a = "+a+" c = "+c);
        }
     
    }


    Voici la classe Main pour ce cas
    Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    public static void main(String... args) {
     
            Runtime runtime = Runtime.getRuntime();
            long debut = System.currentTimeMillis() ;  
     
            List<ExtMClass> list=new ArrayList<>(); 
     
            for(long i=0; i<=5_000_000;i++){
            list.add(new ExtMClass(i,i*10));
            }
            System.out.println("Memoire utilisé:"
                + (runtime.totalMemory()-runtime.freeMemory())/(1024*1024)+" mb");   
             long fin = System.currentTimeMillis() ;
            System.out.println("Le temps écoulé: "+(fin - debut)/1000+ "s");}

    Voici le résultat:
    Memoire utilisé:154 mb
    Le temps écoulé: 1s

    Je tourne sous ubuntu 13.10, sur un Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz avec JDK8. Il a fallu 1s et 154MB déjà 5millions d'objets c'est pas peu, mais regardons si je ne modifie rien je passe juste une référence(pas de pointeur en Java, c'est l'équivalent de pointeur dans d'autre lagunage) à la classe qui étend et je veux avoir les même données pour chaque objet je veux que et si j'avais affiché tous les objets dans le premier cas, voir le même affichage au 2e cas.
    Classe d'Extension par agrégation
    Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    class ExtMClass{   
       MClass m;
       long c;
        public MClass getM() {
            return m;
        }
        public void setM(MClass m) {
            this.m = m;
        }
        public long getC() {
            return c;
    }
    public void affiche(){
           System.out.println("a = "+m.getA()+" c = "+c);
        }
        }
    Code Main du 2e cas
    Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    public static void main(String... args) {
     
            Runtime runtime = Runtime.getRuntime();
            long debut = System.currentTimeMillis() ;  
            MClass m;
            List<ExtMClass> list=new ArrayList<>();   //
     
            for(long i=0; i<=5_000_000;i++){
            list.add(new ExtMClass(new MClass(i),i*10));
            }
            System.out.println("Memoire utilisé:"
                + (runtime.totalMemory()-runtime.freeMemory())/(1024*1024)+" mb");   
            long fin = System.currentTimeMillis() ;
            System.out.println("Le temps écoulé: "+(fin - debut)/1000+ "s");
    }
    Voici le résultat sur le ce 2e cas
    Mémoire utilisé:225 mb
    Le temps: 2s

    C'est totalement le double en CPU et 70mega en mémoire de plus alors que dans tous les cas les données contenus sont les même dans chaque objet des deux cas.
    Toi qui m'a repris sur les librairies, mais tu ne sais pas que des fois on ne peut pas toucher à la classe mère: on casse le contrat
    Je ne t'ai pas repris mais je voulais montrer en quoi tout ce que tu va voir ne sont que des application des principes de base de la POO. Déjà tu dis qu'on si on ne peux pas toucher la classe mère, c'est autre chose, mais il faut savoir que tout ajout dans la classe mère ne casse en rien sur le contrat existant que si on touche aux méthodes existantes ou on supprime certaines, mais l'ajout n'est que définition d'un nouveau contrat, on casse rien.
    Et si on ne peux pas toucher carrément, il y a bien des solutions pour ça en POO et je n'ai jamais dis que seul l'héritage existe.

    Note: pour celui qui veut tester sur une version antérieur à Java 7, il doit juste changer 5_000_000 en 5000000, Java7 a permit plus de visibilité pour le nombres

  20. #40
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Points : 39 749
    Points
    39 749
    Par défaut
    Citation Envoyé par la.lune Voir le message
    On dirait qu'on ne lit pas ce que j'écris
    C'est le syndrome TL;DR... Peut-être que si tes messages n'étaient pas des pavés qui s'étalent sur 3 écrans, les gens seraient plus enclins à les lire

Discussions similaires

  1. Réponses: 27
    Dernier message: 19/09/2006, 10h51
  2. Valeur des formulaire réutilisées dans des requètes SQL.
    Par cotmar dans le forum Requêtes et SQL.
    Réponses: 6
    Dernier message: 09/05/2006, 11h16
  3. Notion de réutilisation dans la programmation
    Par housni dans le forum Langages de programmation
    Réponses: 13
    Dernier message: 04/04/2006, 16h09
  4. Réponses: 4
    Dernier message: 15/03/2006, 12h22
  5. Réponses: 5
    Dernier message: 27/11/2005, 23h07

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo