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

Actualités Discussion :

Faut-il éviter de distraire les débutants avec l'orientée objet ?

  1. #21
    Membre éprouvé
    Avatar de beegees
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mars 2004
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Enseignement

    Informations forums :
    Inscription : Mars 2004
    Messages : 3 610
    Points : 1 277
    Points
    1 277
    Par défaut
    J'ai appris à programmer en procédural. Maintenant que je dois passer à la POO, c'est extrêmement compliqué. Je regrette de ne pas l'avoir fait depuis le début.

  2. #22
    ec
    ec est déconnecté
    Membre confirmé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juillet 2005
    Messages
    214
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Juillet 2005
    Messages : 214
    Points : 554
    Points
    554
    Par défaut Ou... ne parlez pas du changement de vitesses ça distrairait le novice !!!
    J'anime des formations au VBA sur Excel et Access.

    Comment parler de propriétés sans parler d'objet ? Comment parler de méthodes sans parler d'objet ? Comment parler de procédures événementielles sans parler d'objet ? D'une manière générale comment parler de programmation sous Windows sans parler d'objets de façon élémentaire ?

    Ce genre de jugements à l'emporte pièce sont aberrants et ne servent qu'à faire du buzz. Le gars avait du boire un coup de trop ce jour-là.

    C'est comme si un moniteur d'auto-école affirmait "ne parlez pas du changement de vitesses ça distrairait le novice au volant ..."

    Cela veut aussi dire : Surtout, formez à la programmation des gens qui ne peuvent pas manipuler plusieurs concepts à la fois... D'une certaine manière cela s'appelle berner le candidat.

  3. #23
    Membre chevronné Avatar de chaplin
    Profil pro
    Inscrit en
    Août 2006
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 1 215
    Points : 1 819
    Points
    1 819
    Par défaut
    Aujourd'hui, on est habitué a travailler en mode fenêtré, il ne faut pas oublier le mode console. On peut acquerrir des mauvaises habitudes autant en suivant l'un ou l'autre paradigme (procédural, programmation orienté objet).

    Pour du calcul purement scientifique, ce qui prime c'est le résultat, ensuite on décide de l'afficher ou de l'imprimer ou l'enregistrer dans un format de fichier qu'on peut exploiter dans un logiciel graphique.

    On peut également envisager un apprentissage alterné des deux paradigmes, de sorte à avoir un regard simultanné sur les deux approches.

  4. #24
    Membre confirmé
    Profil pro
    Inscrit en
    Juillet 2010
    Messages
    195
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Juillet 2010
    Messages : 195
    Points : 511
    Points
    511
    Par défaut
    Lors de ma formation le premier langage que j'ai appris c'est le pascal, je trouve que c'est une bonne introduction à la programmation et surtout un langage adapté pour faire des problèmes d'algorithmie simple. Mais je pense qu'au cours de sa formation un étudiant en informatique doit voir un peu tout les paradigmes existants (objet, procédural, fonctionnel) et être poussé à être curieux. Car je pense que ce qu'il manque aux étudiants sortant des écoles c'est justement cette curiosité d'aller apprendre par lui même des langages de programmation qu'il n'a pas appris en cours, des technologies qu'il n'a pas vu en cours, etc ... . Je viens de finir mon cursus et je pense qu'on est très peu dans notre promo à avoir appris des langages par pur culture (j'apprend actuellement le clojure), essayer de se renseigner sur des technologies inexistantes des cursus des écoles ( NoSQL et bigdata par exemple ).

  5. #25
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 832
    Points : 2 625
    Points
    2 625
    Par défaut
    Citation Envoyé par chaplin Voir le message
    Aujourd'hui, on est habité a travaillé en mode fenêtré, il ne faut pas oublié le mode console. On peut acquerrir des mauvaises habitudes autant en suivant l'un ou l'autre paradigme (procédural, programmation orienté objet).

    Pour du calcul purement scientifique, ce qui prime c'est le résultat, ensuite on décide de l'afficher ou de l'imprimer ou l'enregistrer dans un format de fichier qu'on peut exploiter dans un logiciel graphique.

    On peut également envisagé un apprentissage alterné des deux paradigmes, de sorte à avoir un regard simultannée sur les deux approches.
    Je ne saisis pas du tout le parallèle console&fenêtre / procédural&objet?
    J'ai même envie de dire qu'il y a plus de programme console qui respectent les paradigmes objet, surtout quand ils obéissent à la philosophie UNIX, qui n'est rien de plus que de l'objet, version ancestrale (ben oui, un programme ne fait qu'une seule chose mais la fait bien, et communique avec les autres au travers d'une interface claire...)

    A part ça...

    Perso, j'ai commencé par le QBasic, puis appris en auto-didacte le C, ensuite l'assembleur (que j'ai appris parce que je me prenais pour un guru en C depuis, j'ai perdu plus d'une taille de chaussettes ça coûte moins cher en tissu ).
    J'ai sincèrement trouvé l'assembleur nettement plus simple que le C:
    _ pas de prise de tête syntaxique
    _ une instruction ne fait qu'une, et une seule chose

    A partir de la, je me suis remis au C, et, étrangement, j'ai compris beaucoup de choses que je n'avais pas comprises auparavant, par exemple, les manipulations de la mémoire sont devenues vachement plus claires.
    Ah, et l'art de déboguer un programme à la trace est aussi nettement plus efficace depuis.

    Pour ce qui est de l'apprentissage, je ne pense pas que l'on doit enseigner un seul paradigme à la fois.
    A mon humble avis, il serait intéressant d'enseigner les langages de scripts du genre shell, ou l'on combine de petits programmes de façon procédurale en même temps qu'un langage type ASM qui permet de comprendre comment la machine marche, en faisant de très petits trucs.

    L'intérêt?
    L'assembleur, c'est du pur procédural. Le Shell, c'est manipuler des objets par leur interface connue.
    Une fois initié à ces deux techniques, je crois qu'en fait on a abordé comment se servir des objets, et comment implémenter une petite partie d'entre eux (les méthodes).
    Quand on a ces notions, on peut passer à l'orienté objet, en expliquant aux étudiants qu'en fait, ils font de l'objet depuis qu'ils font du script. Il suffit de leur demander d'implémenter des classes qui reproduisent le comportement de commandes simples, et de faire un programme qui singe un des scripts qu'ils ont fait précédemment.
    De cette façon, peut-être que les gens auront moins peur de l'objet.

    Ah, oui, ça fait peur, quand je dis assembleur, ou apprendre comment marche une machine. Cela dis, pour moi, un mécano si on lui dis qu'il faut changer telle ou telle pièce dans tel ou tel cas, si il ne comprend pas pourquoi, il faudra le former à chaque nouvelle voiture.
    Si il connaît les bases, il sera capable de comprendre d'instinct un certain nombre de choses.

    Ok, c'est long. Mais j'aimerai savoir, à votre avis, la programmation, c'est un métier, ou pas?
    D'ailleurs, les grandes lignes d'un ordinateur, ça n'est pas si complexe que ça. Et quand bien même... de nos jours, on a tendance à dire qu'il faut enseigner aux gens directement un truc utile en entreprise. Je le pensais aussi, *avant*. Pourquoi j'ai changé d'avis? Parce que les entreprises, ça change de techno, et que le temps qu'un type fasse ses 5 ans d'étude, la techno qu'il a utilisée peut très bien être complètement obsolète (sans compter le temps qu'il faut à l'éducation nationale pour admettre qu'une techno est obsolète).

    Quand aux différents paradigmes...
    Chacun est une façon de penser. Chaque problème peut se résoudre de plusieurs façons. Ok, le procédural, c'est la façon de penser la plus humaine et donc le paradigme le plus simple. N'empêche, je pense qu'on devrait apprendre plusieurs paradigmes, parce que sinon il est très difficile de s'y mettre quand on a pris des habitudes. J'essaie de me mettre au prolog... ben... j'ai un mal de chien, parce que le paradigme n'a juste rien à voir.
    Pourtant, plusieurs paradigmes permettent d'attaquer un problème avec plusieurs angles, et de choisir le meilleur pour le résoudre.

    Si on a qu'une pioche pour percer un trou dans un mur, on y arrivera, mais c'est plus simple d'avoir un burin parfois. Alors que dans le sol, le burin sera presque inutile.

  6. #26
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    Novembre 2002
    Messages
    8 964
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : Novembre 2002
    Messages : 8 964
    Points : 28 430
    Points
    28 430
    Par défaut
    Citation Envoyé par beegees Voir le message
    J'ai appris à programmer en procédural. Maintenant que je dois passer à la POO, c'est extrêmement compliqué. Je regrette de ne pas l'avoir fait depuis le début.
    le passage du procédure à l'objet peut se faire en douceur si c'est bien appréhendé.

    qu'est-ce qu'un objet ? rien d'autre qu'un structure à laquelle on associe des fonctions ou méthodes statiques. Les méthodes virtuelles sont quand à elle des pointeurs vers des fonctions que l'on place DANS la structure afin de pouvoir les modifier (polymorphisme). Et en regroupant un ensemble de méthodes dans une liste ordonnée on obtient une interface !

    quand on a compris ça (ce qui nécessite de connaître la programmation procédural) on a fait un grand pas dans l'objet, il ne reste plus qu'à comprend pourquoi ces structures sont pratiques et en quoi une couche objet dans le langage nous facilite la vie.

    j'ai le sentiment - bien que j'ai moi même commencé par le procédural - que quand on commence avec l'objet, on perd la connaissance de l'intérêt de la chose...ce qui rejoint un peu l'idée de départ de ce fil.
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  7. #27
    Membre éprouvé
    Avatar de beegees
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mars 2004
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Enseignement

    Informations forums :
    Inscription : Mars 2004
    Messages : 3 610
    Points : 1 277
    Points
    1 277
    Par défaut
    Citation Envoyé par Paul TOTH Voir le message
    le passage du procédure à l'objet peut se faire en douceur si c'est bien appréhendé.
    J'aime beaucoup cette phrase, mais "si c'est bien appréhendé" me semble le plus important.

    Le problème est que je fais des choses sans savoir si je les fait correctement.

    Par exemple : http://www.developpez.net/forums/d12...o/#post6831496

    Bonne soirée.

    bee

  8. #28
    Membre chevronné Avatar de chaplin
    Profil pro
    Inscrit en
    Août 2006
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 1 215
    Points : 1 819
    Points
    1 819
    Par défaut
    Citation Envoyé par Paul TOTH Voir le message
    ... j'ai le sentiment - bien que j'ai moi même commencé par le procédural - que quand on commence avec l'objet, on perd la connaissance de l'intérêt de la chose...ce qui rejoint un peu l'idée de départ de ce fil.
    J'ai fait l'expérience d'enseigner l'objet à une personne de plus de 60 ans. Avec son approche "naive" du sujet, j'ai compris que la partie la plus complexe de la programmation objet réside dans la compréhension de la communication entre les objets. Tant que le nouvel apprenti n'a pas saisie ce principe, c'est bloquant.

    Quand on a un passé lourd en procédural, c'est difficile de changer ses habitudes, à fortiori, on est induit en erreur.

  9. #29
    Membre habitué
    Profil pro
    Inscrit en
    Novembre 2003
    Messages
    74
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2003
    Messages : 74
    Points : 137
    Points
    137
    Par défaut
    Citation Envoyé par chaplin Voir le message
    J'ai fait l'expérience d'enseigner l'objet à une personne de plus de 60 ans. Avec son approche "naive" du sujet, j'ai compris que la partie la plus complexe de la programmation objet réside dans la compréhension de la communication entre les objets. Tant que le nouvel apprenti n'a pas saisie ce principe, c'est bloquant.

    Quand on a un passé lourd en procédural, c'est difficile de changer ses habitudes, à fortiori, on est induit en erreur.
    Je te rejoins.

    Je pars d'un constat : On ne pense pas à "comment l'objet va faire" pour concevoir correctement en Objet. On pense à "qu'est ce que va faire l'objet".
    C'est une base (cf. UML).
    edit : Je pense qu'apprendre en premier l'un ou l'autre importe peu. L'erreur est de les utiliser au mauvais moment

  10. #30
    Membre habitué
    Profil pro
    Inscrit en
    Novembre 2003
    Messages
    74
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2003
    Messages : 74
    Points : 137
    Points
    137
    Par défaut
    Citation Envoyé par Paul TOTH Voir le message
    le passage du procédure à l'objet peut se faire en douceur si c'est bien appréhendé.

    qu'est-ce qu'un objet ? rien d'autre qu'un structure à laquelle on associe des fonctions ou méthodes statiques. Les méthodes virtuelles sont quand à elle des pointeurs vers des fonctions que l'on place DANS la structure afin de pouvoir les modifier (polymorphisme). Et en regroupant un ensemble de méthodes dans une liste ordonnée on obtient une interface !

    quand on a compris ça (ce qui nécessite de connaître la programmation procédural) on a fait un grand pas dans l'objet, il ne reste plus qu'à comprend pourquoi ces structures sont pratiques et en quoi une couche objet dans le langage nous facilite la vie.

    j'ai le sentiment - bien que j'ai moi même commencé par le procédural - que quand on commence avec l'objet, on perd la connaissance de l'intérêt de la chose...ce qui rejoint un peu l'idée de départ de ce fil.
    qu'est-ce qu'un objet ? rien d'autre qu'un structure à laquelle on associe des fonctions ou méthodes statiques.
    Je trouve cette affirmation bien trop aveuglante. Pour percevoir "une voiture" comme un objet (c'est une base), on ne cherche pas dans la voiture quelle est la structure à laquelle on associe des fonctions ou méthodes statiques. Pour percevoir "une voiture" comme un objet, on perçoit les interaction de la voiture avec le monde extérieur (personnes-volant, sol-roues, essence-réservoir, air-pot d’échappement, ect.). C'est seulement quand on a apprit à l'identifier dans le contexte, qu'on apprend à l'identifier dans la technique (méthodes, surcharges, polymorphisme).

    il ne reste plus qu'à comprend pourquoi ces structures sont pratiques et en quoi une couche objet dans le langage nous facilite la vie.
    Je ressens cette affirmation fausse, néfaste et hors sujet.
    Qu'elles soient si pratique et qu'elles facilitent la vie sont des conséquences de leurs utilisations, pourquoi affirmer que ce sont des causes?

    j'ai le sentiment - bien que j'ai moi même commencé par le procédural - que quand on commence avec l'objet, on perd la connaissance de l'intérêt de la chose...
    Tout est dit.
    On perd la connaissance de l'intérêt de la chose quand on perçoit incorrectement l'objet (la chose).

  11. #31
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 386
    Points
    9 386
    Par défaut
    Citation Envoyé par jnspunk Voir le message
    qu'est-ce qu'un objet ? rien d'autre qu'un structure à laquelle on associe des fonctions ou méthodes statiques.
    Je trouve cette affirmation bien trop aveuglante. Pour percevoir "une voiture" comme un objet (c'est une base), on ne cherche pas dans la voiture quelle est la structure à laquelle on associe des fonctions ou méthodes statiques. Pour percevoir "une voiture" comme un objet, on perçoit les interaction de la voiture avec le monde extérieur (personnes-volant, sol-roues, essence-réservoir, air-pot d’échappement, ect.). C'est seulement quand on a apprit à l'identifier dans le contexte, qu'on apprend à l'identifier dans la technique (méthodes, surcharges, polymorphisme).
    Pau TOTH ne parlait pas de comment on fait de l'objet, mais comment on peut passer facilement niveau compréhension du paradigme procédural à celui de l'objet...

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  12. #32
    Membre habitué
    Profil pro
    Inscrit en
    Novembre 2003
    Messages
    74
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2003
    Messages : 74
    Points : 137
    Points
    137
    Par défaut
    Citation Envoyé par transgohan Voir le message
    Pau TOTH ne parlait pas de comment on fait de l'objet, mais comment on peut passer facilement niveau compréhension du paradigme procédural à celui de l'objet...
    Elle se fait facilement uniquement pour ceux qui ont déjà acquis les deux compréhensions.
    Ce qui me choque, c'est que des personnes peuvent mal interpréter ses propos et faussement croire qu'elles pourront passer du procédurale à l'objet avant d'en acquérir la compréhension.
    Les deux doivent s'apprendre séparément au début, chacune à son contexte; c'est un piège sournois de les mélanger à ce moment!

  13. #33
    Membre averti Avatar de magnus2005
    Profil pro
    Ingenieur SI
    Inscrit en
    Avril 2005
    Messages
    454
    Détails du profil
    Informations personnelles :
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingenieur SI

    Informations forums :
    Inscription : Avril 2005
    Messages : 454
    Points : 331
    Points
    331
    Par défaut
    Il faut proscrire la programmation procédurale comme 1er approche de l'apprentissage de la programmation j'en voie le désastre depuis trop d'années. Il apparait qu'une fois que l'esprit humain à acquis ce en premier concept il parvient difficilement à appréhender la POO. Les professeurs qui repende cette archaïsme de penser comme quoi ce serait plus simple, ne pense cela que parce qu'il ne parvienne pas eux même à appréhender la POO et ceci répète le schéma.

    Apprendre la POO en tant que 1er approche permet ensuite de facilement appréhender les autres concepts. Je peux le vérifier tous les jours. A mon sens le paradigme de la POO finalement englobe le procédurale.

    Effectivement il ne faut pas se tromper sur la question poser qui est sur l'apprentissage des paradigmes mais je ferais quand même la remarque suivante à Paul TOTH :

    Oui d'un point de vue technique tous revient en général à C et à de l'assembleur, mais ce sont des techno qui ne réponde plus à la conception d'application pour les utilisateurs. Le C était du haut niveau, le C++ l'a fait descendre d'un cran, Java et .NET ont fait descendre le C++ d'un cran.

    Tes remarques sont vrai uniquement sur le C++ qui est du C à la base et rappel les temps reculés ou la POO n’était pas utilisable faute de solution technique.
    Effectivement avant les années 90 les langages de programmation n'offrait pas une gestion de la POO correcte mais depuis le C++ cela ne pose plus de problème.

    Je croise tous les jours des personnes des personnes dans ton cas.
    Finalement je ne sais ceux qui posent le plus de problème les adeptes du C ou les Ex-COBOLISTE.

  14. #34
    Membre du Club
    Homme Profil pro
    Développeur logiciel
    Inscrit en
    Octobre 2009
    Messages
    45
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

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

    Informations forums :
    Inscription : Octobre 2009
    Messages : 45
    Points : 64
    Points
    64
    Par défaut
    Je suis un jeune programmeur de trois ans, de mon experience et ma facilité d'évolution je suis pour le fait de commencer par les langages non orientée objet tels aue Pascal, C pour apprendre a se concentrer sur la résolution des problemes (pétits problèmes bien sur ) que de réflechir pendant des heures sur l'aspect structurelle d'une application. Présentement je fais de la POO parce que mes applications sont complexes et elles doivent etre maintenables, evolutives.

  15. #35
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    Novembre 2002
    Messages
    8 964
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : Novembre 2002
    Messages : 8 964
    Points : 28 430
    Points
    28 430
    Par défaut
    Citation Envoyé par beegees Voir le message
    J'aime beaucoup cette phrase, mais "si c'est bien appréhendé" me semble le plus important.

    Le problème est que je fais des choses sans savoir si je les fait correctement.

    Par exemple : http://www.developpez.net/forums/d12...o/#post6831496

    Bonne soirée.

    bee
    ta question est légitime "Je trouve que ça fait beaucoup de code et peu d'avantage par rapport à ce que je faisais avant (procédural) ?"

    c'est en effet le sentiment qu'ont probablement tous les programmeurs procéduraux qui passent à l'objet c'est pour cela qu'il est bien - pour eux en tout cas - de démystifier l'objet.
    A partir du moment ou tu trouves pratique dans tes procédure de regrouper des paramètres dans des structures, que ces structures sont systématiquement passées en paramètre de tes fonctions, tu fais déjà de l'objet sans le savoir. A mon avis tant que tu ne vois pas l'intérêt de l'objet abstient toi (surtout en PHP), tu feras pire que mieux.
    Dernier exemple en date dans mes développement PHP qui sont majoritairement procéduraux, un objet Wiki qui converti un texte wiki en html...faire tenir cela dans une seule fonction est douteux, l'objet permet ici de regrouper tout ce dont j'ai besoin pour wikifier mon texte sans avoir à passer de paramètre à mes fonction ou utiliser des globaux car ce sont les propriétés de l'objet qui servent de paramètre...il m'arrive aussi d'utiliser un unique tableau comme paramètre d'une série de fonction...et là encore c'est de l'objet déguisé.

    Ensuite, je suis un programmeur "technique", peu importe ce que je programme, j'ai une approche très mécanique de mes traitements. Un object reste pour moi une structure avec des pointeurs. Mais, pour répondre à jnspunk et magnus2005, il y a en effet une autre approche de la programmation objet - plus "puriste" - qui se désintéresse du langage et de la technique. Dans cette approche les langages sont parfois même insuffisants pour traduire la quintessence de l'objet, et la théorie se heurte aux limites des implémentations du langage.

    Je n'ai pas cette vision "noble" de l'objet, je suis pragmatique, l'objet est pour moi un outil, parfois indispensable, mais pas systématique.
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  16. #36
    Membre habitué
    Profil pro
    Inscrit en
    Novembre 2003
    Messages
    74
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2003
    Messages : 74
    Points : 137
    Points
    137
    Par défaut
    Citation Envoyé par Paul TOTH Voir le message
    ta question est légitime "Je trouve que ça fait beaucoup de code et peu d'avantage par rapport à ce que je faisais avant (procédural) ?"

    c'est en effet le sentiment qu'ont probablement tous les programmeurs procéduraux qui passent à l'objet c'est pour cela qu'il est bien - pour eux en tout cas - de démystifier l'objet.
    A partir du moment ou tu trouves pratique dans tes procédure de regrouper des paramètres dans des structures, que ces structures sont systématiquement passées en paramètre de tes fonctions, tu fais déjà de l'objet sans le savoir. A mon avis tant que tu ne vois pas l'intérêt de l'objet abstient toi (surtout en PHP), tu feras pire que mieux.
    Dernier exemple en date dans mes développement PHP qui sont majoritairement procéduraux, un objet Wiki qui converti un texte wiki en html...faire tenir cela dans une seule fonction est douteux, l'objet permet ici de regrouper tout ce dont j'ai besoin pour wikifier mon texte sans avoir à passer de paramètre à mes fonction ou utiliser des globaux car ce sont les propriétés de l'objet qui servent de paramètre...il m'arrive aussi d'utiliser un unique tableau comme paramètre d'une série de fonction...et là encore c'est de l'objet déguisé.

    Ensuite, je suis un programmeur "technique", peu importe ce que je programme, j'ai une approche très mécanique de mes traitements. Un object reste pour moi une structure avec des pointeurs. Mais, pour répondre à jnspunk et magnus2005, il y a en effet une autre approche de la programmation objet - plus "puriste" - qui se désintéresse du langage et de la technique. Dans cette approche les langages sont parfois même insuffisants pour traduire la quintessence de l'objet, et la théorie se heurte aux limites des implémentations du langage.

    Je n'ai pas cette vision "noble" de l'objet, je suis pragmatique, l'objet est pour moi un outil, parfois indispensable, mais pas systématique.
    Je te rejoins entièrement.
    Cette vision "noble", en pratique, n'est pas systématique. Le fleuriste n'utilise pas une tronçonneuse pour couper une rose, certes ça fait peur au client

    Je pense que penser "Objet" dépend de beaucoup de facteur, que chacun à sa manière de le concevoir, tant que chacun en a comprit l'essence, ils ne peuvent faire fausse route.

  17. #37
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Bonjour,

    Citation Envoyé par magnus2005 Voir le message
    Il faut proscrire la programmation procédurale comme 1er approche de l'apprentissage de la programmation j'en voie le désastre depuis trop d'années. Il apparait qu'une fois que l'esprit humain à acquis ce en premier concept il parvient difficilement à appréhender la POO.


    Oui d'un point de vue technique tous revient en général à C et à de l'assembleur, mais ce sont des techno qui ne réponde plus à la conception d'application pour les utilisateurs. Le C était du haut niveau, le C++ l'a fait descendre d'un cran, Java et .NET ont fait descendre le C++ d'un cran.

    Effectivement avant les années 90 les langages de programmation n'offrait pas une gestion de la POO correcte mais depuis le C++ cela ne pose plus de problème.

    Je croise tous les jours des personnes des personnes dans ton cas.
    Finalement je ne sais ceux qui posent le plus de problème les adeptes du C ou les Ex-COBOLISTE.
    Il se trouve que je suis developpeur C, donc je me permet de repondre car je ne suis pas d'accord, dans la mesure ou tous mes programmes suivent une conception objet.

    Certes, ca demande un peu plus de rigueur au developpeur C pour faire de l'assimile-objet, vu que tout (notamment les fonctions) est accessible de partout ; a lui donc de se restreindre et de ne pas faire n'importe quoi n'importe ou.

    Et cela fonctionne tres bien, je n'ai pas eu trop de remarques negatives sur la qualite globale de mon code, ni sur la conception.


    Et pour enfoncter le clou, j'ai appris le Pascal, puis le C, puis seulement la POO.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  18. #38
    Invité
    Invité(e)
    Par défaut
    Je suis assez d'accord avec l'article. Au début de l'apprentissage, l'approche procédurale est très naturelle, parce qu'elle correspond bien à l'idée qu'on se fait d'un programme : une petite machine qui "fait quelque chose". Elle permet aussi d'enseigner rapidement l'algorithmique, et la grammaire du langage, qui seront de toutes façons nécessaires.

    En revanche, on peut dès le début parler de types de données, de structuration du code en regroupant données et traitements, voire d'encapsulation, ce qui prépare à l'objet.

    A mon avis, l'objet apparait très naturellement un peu plus tard, comme solution aux problèmes d'architecture, et il est plus facile à comprendre dans ce contexte, un fois qu'on a rencontré ces problèmes. Un défaut des jeunes programmeurs "pur objet" est souvent qu'ils n'essaient de raisonner que de manière abstraite, ce qui marchera sur des problèmes simples, mais à peu près jamais quand ca se complique (l'abstraction, c'est très difficile).


    Ce raisonnement est aussi valable lors de la conception initiale d'un projet. Un gros défaut des programmeurs "pur objet" est de chercher à spécifier l'architecture et les concepts au tout début, à un moment où l'on n'a généralement pas une vision claire des besoins et des contraintes. C'est ce qui mène aux architectures démentes qu'on voit ici et là, et avec lesquelles il faut vivre, parce qu'un "spécialiste" les a imaginées trop tôt.

    Pour moi, la recommandation qu'on trouve dans certains manuels de commmencer par identifier les objets est très dangereuse en pratique. Les bons objets ne sont pas du tout intuitifs, et n'apparaissent qu'à l'usage.

    Pour reprendre l'exemple de la voiture et du véhicule, la première charette à moteur n'était pas une "voiture", elle n'a pas été construite sur la base d'un cahier de spécifications pondu par un jeune administratif après des entretiens utilisateurs. C'était un assemblage hétéroclite, répondant à un besoin vague, qu'on a amélioré à l'usage.

    C'est exactement pareil avec un programme un tant soit peu complexe.

    Francois

  19. #39
    Membre averti Avatar de magnus2005
    Profil pro
    Ingenieur SI
    Inscrit en
    Avril 2005
    Messages
    454
    Détails du profil
    Informations personnelles :
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingenieur SI

    Informations forums :
    Inscription : Avril 2005
    Messages : 454
    Points : 331
    Points
    331
    Par défaut
    Oui il y aura toujours des développeurs capable d’appréhender tous les aspects techniques quelque que soit le langage ou les paradigmes utilisés. Ce sont des personnes qui avait reçu un enseignement basé sur le paradigme du procédural qui ont construit tous les programmes d'enseignements de la POO.

    Mais le problème de l'enseignement est un problème globale comme l'enseignement de la lecture à l’école primaire. Il faut employer la méthode qui donne les meilleurs résultats sur la majorité des élèves. Passer par la POO en premier fait que passer au procédurale après se passe sans souci alors que pour le contraire la plupart des développeur procéduraux reste bloqués dans ce schéma mental.
    Plus grave encore il y en a même qui sont bloqué dans des schéma du type (en utilisant des langages modernes) avec du code avec zéro fonctions. Le programme commence en haut et finit en bas plusieurs milliers de ligne après.

    Autre point professionnellement parlant le type de développement les plus répandus sont ceux du type application gestion ou il faut vraiment proscrire l'utilisation des langages de développement systèmes (C et C++) pour utiliser les langages POO adaptés (Ex : C#, Java, PHP) et vice versa faire un kernel d'un OS en Java ou en PHP c'est pas gagné. Donc apprendre la procédurale est vain car ces développeurs eux car il ne devront faire que de la POO.

    Autre point ce sont des développeurs qui n'ont pas conscience de l'existence de la gestion de la mémoire et des pointeurs. Je prend l'exemple des BTS et des DUT il vaut mieux passer 2 ans pour former un développeur d'application de gestion correcte qu'un développeur systèmes médiocres car il est constaté que d’élèves sont souvent été perdu par la gestion de la mémoire en C/C++ ce qui les empêche de se concentrer sur le fonctionnement globale des applications.
    Je prend un exemple tous simple le C++ n'a jamais été en mesure de concurrencé le COBOL dans le monde professionnel et pourtant techniquement parlant le C++ est très supérieur au COBOL (c'est ce que pensais à mes début en tant que développeur C++). Java (et d'autre) ont permis une transition réel vers la fin du COBOL car il solutionne la plupart des problèmes du C++ (du point de vue du COBOL) qui finalement est trop puissant et permet de fait tout (et surtout n'importe quoi, bienvenue dans le monde réel).

    J'aimerais faire remarquer ceci des gens qui lisent une discussion du type :
    Faut-il éviter de distraire les débutants avec l'orientée objet ?
    C'est ce je voudrais avoir comme membre des équipes mais force de constaté que la plupart des développeurs lambda ne sont pas passionné par leur boulot et font un dump mémoire dès qu'il ont franchi la porte hors du bureau (parfois même avant).

    A mon sens il y a 3 niveau de développeurs :
    1. Les développeurs qui ne cherchent absolument pas à comprendre ce qu'il font du point de vue technique mais force de constaté que cela ne les empêche de livré dans les temps des applications répondant à un cahier des charges.
    2. Ceux qui comprennent le fonctionnel et la technique (l'idéal mais c'est une minorité) .
    3. Ceux qui font acharné de la technique. Eux il ne livrent jamais dans les délais et ce n'est jamais ce qu'on demandé les utilisateurs.


    Le développement c'est des humains et des langages et des paradigmes. Commencer par la POO fait que le mixage de tous ça donne les résultats les plus solides. C'est une question de gestion RH.

    Ce serait bien que tous les développeurs maitrise toutes les bases mais ça c'est vrai dans le monde bisounours, dans le monde de l'entreprise les gens sont spécialisés et le deviennent de plus en plus avec le temps et pour la plupart des gens se remettent difficilement en question. En apprenant la POO en premier il n'est pas nécessaire de remettre tout à plat pour faire du procédurale.

    Exemple final :
    Les acharnés sont toujours pénibles :
    mais les acharnés de l'objet le sont moins que ceux du procédurale parce qu'ils comprennent toujours le procédurale.

  20. #40
    Membre averti Avatar de magnus2005
    Profil pro
    Ingenieur SI
    Inscrit en
    Avril 2005
    Messages
    454
    Détails du profil
    Informations personnelles :
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingenieur SI

    Informations forums :
    Inscription : Avril 2005
    Messages : 454
    Points : 331
    Points
    331
    Par défaut
    Je suis désole pour fcharton mais c'est typiquement la schéma de réflexion que l'on retrouve par ceux qui ont commencé par apprendre du procédurale.
    Le mode de fonctionnement d'un CPU n'est pas naturelle pour un humain. Il parait cohérent pour un développeur après acquisition de nombreux concept.

    Il est naturel pour un humain :
    D'utiliser une cafetière pour faire :
    • un café
    • un cappucino


    D'utiliser une voiture pour faire :
    • demarrer
    • avancer


    D'utiliser une Fichier (objet)pour faire :
    • deplacer (méthode)
    • effacer (méthode)


    Cela est naturel pour tous les gens impliqués dans un projet :
    Les clients, les analystes , les développeurs.

    Ma démonstration est simple et il y a que les gens qui sont primo formés au procédural qui argue que cela n'est pas naturel.
    Êtes vous d'accord ?

    Je suis d'accord avec transgohan chaque paradygme à son utilité
    mais la POO doit être le primo enseignement.

Discussions similaires

  1. Association inverse dans les bases de données orientées objet
    Par kochfet dans le forum Optimisations
    Réponses: 0
    Dernier message: 05/07/2014, 11h30
  2. Tableau html avec évènements. Orienté objet ou non ?
    Par tidus_6_9_2 dans le forum Général JavaScript
    Réponses: 1
    Dernier message: 29/09/2010, 12h12
  3. Réponses: 0
    Dernier message: 06/06/2008, 09h41
  4. débutante avec les threads
    Par dc.sara dans le forum Réseau
    Réponses: 2
    Dernier message: 10/12/2007, 12h08
  5. Débutant avec les Threads
    Par Invité dans le forum AWT/Swing
    Réponses: 18
    Dernier message: 13/06/2007, 18h58

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