Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par tarikbenmerar

0PARTAGES

17  5 
Faut-il apprendre à un débutant l'orienté objet ? Pour ou contre ? L'avis de James Hague est en tout cas tranché.

Dans un récent billet de son célèbre blog "programming in the twenty-first century", il plaide contre l'introduction de ce concept au nouveau programmeur sous peine de trop les « distraire ».

Hague prend l’exemple de Python, qu’il considère comme un langage où les solutions sont souvent simples à implémenter. Bref, un langage d’introduction idéal pour le débutant, avec une élégance particulière dans l’utilisation des types de donnée de base tels que les dictionnaires. Néanmoins, il estime qu’il faut éviter à tout prix de parler de l'orienté objet, et se contenter de ces outils de base qui s'avèrent assez efficaces pour résoudre la majorité des problèmes pratiques.

Selon Hague, l'introduction de l'orienté objet force le programmeur « à réfléchir non pas en terme de problème et de solution, mais en terme d'architecture ». Pour résumer, l'introduction de nouveaux artefacts issus de la POO ne fera que distraire le programmeur de l'objectif principal, à savoir la résolution du problème.

Ainsi, certains débutants vont jusqu'à abuser de ces concepts, et se retrouvent à créer des hiérarchies inutiles de classes, s'éloignant complètement de ce qu'il faut réellement apprendre.
D'autres groupes se désintéresseront complètement, parce qu’ils trouveront cette couche additionnelle sans sens concret, et rends la programmation encore plus encombrante et lourde.

« À un moment donné, oui, vous devrez aborder la création d'objets sous Python, mais résistez à la tentation de le faire aussi longtemps que vous le pouvez », conseille-t-il.

Et vous ?

Faut-il, d'après vous, éviter de distraire les débutants avec la programmation orientée objet ?
Ou est-il préférable de l'enseigner en premier ?
Python est-il le langage idéal pour apprendre la programmation ?
Ou estimez-vous que d'autres langages remplissent mieux cette tâche ?

Source : Don't Distract New Programmers with OOP

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 03/08/2012 à 12:40
il faut arrêter de penser que "développeur" est un métier unique.

on ne développe pas sous Java, PHP, C++ et VisualBasic de la même façon.

on ne développe pas ComptaFacile, Amadeus et VotrebanqueEnLigne de la même façon (enfin j'espère pour compte compte en ligne).

dernièrement j'ai vu un logiciel de caisse "développé" sous Excel, on coche des prestations et on renseigne la remise et la case "total" donne le montant à payer...les clients sont gérés sur papier...pas besoin d'apprendre la programmation orientée objet pour faire ça. Je ne sais pas si la feuille contient un peu de VBA ou si tout est géré par formule ceci dit.

Or donc, la première question, c'est à quoi veut-on les former ?
27  2 
Avatar de stardeath
Membre expert https://www.developpez.com
Le 03/08/2012 à 12:29
je suis toujours ébahi par les avis à l'emporte pièce sur la manière d'enseigner la programmation ; pas de pointeurs c'est oldschool et trop difficile, pas d'héritage multiple c'est dangereux, pas de template, les messages d'erreurs sont trop incompréhensibles ...

en entendant ça, ça m'étonne pas que les jeunes diplômés ne savent rien faire, soit on leur apprend du tellement haut niveau que libérer la mémoire devient du chinois soit on limite les langages à if-the-else-for-while et dès qu'on sort de ça ils ne savent plus faire.

rien ne vaut c/c++ et 2-3 bribes d'assembleur pour l'apprentissage, au moins les jeunes seront parés pour tout et seront moins surpris si on leur demande de libérer la mémoire (tout le contraire si ils ont commencés par un langage avec gc ...)
26  5 
Avatar de CapFlow
Membre actif https://www.developpez.com
Le 03/08/2012 à 12:06
Je pense que pour un débutant, il vaut mieux commencer à apprendre la POO après avoir acquis une bonne maitrise du langage en question. Et il faut qu'il s'en sente capable bien sur.

« à réfléchir non pas en terme de problème et de solution, mais en terme d'architecture »
Tout à fait d'accord, quand on commencer à développer avec de la programmation orientée objet, le problème n'est plus "comment faire ceci ?" mais "comment vais-je structurer mon programme ?". C'est pour cela qu'une bonne maitrise du langage utilisé est nécessaire pour savoir avant de commencer à écrire le code comment faire son programme.
21  1 
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 03/08/2012 à 19:02
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.
13  0 
Avatar de
https://www.developpez.com
Le 05/08/2012 à 14:53
Citation Envoyé par magnus2005 Voir le message

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.
Non, c'est le raisonnement de tous ceux qui voient l'informatique comme une généralisation du calcul, tel qu'on l'apprend au primaire. Ou de la façon dont on a appris à lire (des lettres qui font des syllabes qui font des mots, qui font des phrases, qui font du sens, de façon assez linéaire, je crois).

C'est pour cela que je dis qu'il est naturel.

L'approche procédurale fait sens pour un très grand nombre d'applications de l'informatique. En fait, partout où l'on raisonne en termes de "traitement" ou de "calcul".

L'approche objet est adaptée à des situations particulières. A mon avis, elle est avant tout utile pour les interfaces utilisateur, les programmes de type "simulation" (où l'on a par nature des objets qui interréagissent de façon indépendante, cette situation est courante dans les jeux), et *éventuellement* des structures de très grande taille, de façon à réduire les interactions entre modules distincts. Mais dans ce dernier cas, elle n'est qu'une solution à la mode parmi d'autres.

Mais, en fin de compte, tout émane du procédural, parce que ce type de raisonnement qui sépare données et traitements, et découpe chaque traitement en fonctions est à la base du raisonnement humain. Regardez la grammaire : on a des noms (données) et des verbes (traitements) qu'on applique en des procédures linéaires (phrases). C'est pareil en maths, en comptabilité aussi...

Alors, on peut reprocher à ce formalisme scientifique de mal représenter le monde réel, de ne pas savoir qu'un cappucino est un café, ou qu'une porte peut d'ouvrir, comme un livre, ou une boite de conserve. Mais c'est un mauvais procès, car en dehors d'applications de simulation où l'on demande au programme de "faire comme dans le monde réel", ce n'est pas l'objet de l'informatique.

On a maintenant du recul sur les générations "formées à l'objet". Mon impression c'est que les grandes promesses de simplification du code, d'amélioration de la maintenance, n'ont pas plus été tenues par l'objet que par les solutions miracles qui l'ont précédé, ce qui fait qu'on a aujourd'hui de la POO une vision plus modeste qu'il y a une vingtaine d'années. Par ailleurs, on peut constater que l'insistance mise sur l'objet, surtout quand on lui ajoute l'UML comme point de passage obligé, et les design pattern comme évangile, renforce chez certains un gout de l'abstrait pour l'abstrait qui produit rarement du bon travail (en informatique comme ailleurs).

Bref, l'objet est passé dans les moeurs, tout le monde en fait, à des niveaux différents. Mais ceux qui lui accordent une trop grande importance font l'objet d'une méfiance assez générale.

Francois
12  1 
Avatar de Freem
Membre émérite https://www.developpez.com
Le 03/08/2012 à 17:16
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.
9  0 
Avatar de
https://www.developpez.com
Le 07/08/2012 à 2:04
Citation Envoyé par magnus2005 Voir le message
Il faut avant leur enseigner comment analyser une demande client et comment y répondre.
Aux élèves? Ca me parait très présomptueux, car suivant le métier qu'ils feront les clients et leurs demandes varieront.

Et j'éviterai aussi de mettre ce genre de sujet dans des cursus universitaires où une partie des enseignants a une idée assez approximative du monde de l'entreprise.

Citation Envoyé par magnus2005 Voir le message

A titre de chef de projet sur des applications de gestion, finalement force de constater que ce n'est absolument pas un critère discriminant pour attribuer des primes et évaluer un développeur.
Ca me parait être davantage un argument contre le travail dans des structures comme la tienne que pour la POO...

Parce que, "code maintenable" ça ne veut à peu près rien dire à court terme. En fait, neuf fois sur dix, ca veut juste dire respecter la charte stylistique, et mettre un maximum de commentaires inutiles. C'est sur le moyen terme qu'on juge de la maintenabilité, et on l'obtient presque toujours au prix de délais supplémentaires (en fait de réécritures en milieu de projet, quand on commence à avoir un peu de visibilité sur les vrais problèmes, les limites de l'existant, et la direction des évolutions futures).

Ensuite, "livré dans les temps", ça veut presque toujours dire bâclé, parce que les prévisions sont toujours optimistes, les difficultés sous estimées, les fonctionnalités "complétées" en cours de route. Et la victime idéale de ce genre de situation, c'est justement la maintenabilité.

En tant que développeur, j'éviterais une telle structure...

En tant que patron, j'ai tendance à récompenser, dans cet ordre
- la fiabilité du code produit
- la capacité à tester, et ne pas se noyer dans un compte rendu de bug
- l'équilibre entre ambition (ne pas toujours maintenir et faire du code "petit bras" et réalisme

Les délais, c'est à moi de les faire passer aux clients, pas aux développeurs de les tenir. Et la maintenabilité, ce n'est pas assez mesurable à court terme pour servir de base à des primes (mais c'est un excellent critère pour décider des évolutions à long terme).

Citation Envoyé par magnus2005 Voir le message
je viens de faire passer une équipe du développement procédurale à la POO. maintenant mes supérieurs entende des délais de type semaine/mois à la place d'année/voir jamais. Il serait simpliste de dire que ce n'est uniquement de la POO mais à mon avis il y a contribué grandement.
Sérieusement, si la POO était la solution magique qui transforme les années hommes en mois hommes et rendait les solutions maintenable, ce débat n'existerait pas, et on ne dirait pas POO, mais programmation tout court.

Je ne connais pas ta situation, mais je pense que la principale raison du gain de temps est probablement la mise au pas d'une équipe hétéroclite, par la mise en place de méthodes communes. Le passage à une méthodologie nouvelle (la POO ici) est une solution classique.

Mais j'ai quand même un doute... Mon expérience, c'est que l'objet, sur les sujets où il fonctionne, nécessite souvent un investissement plus lourd (donc des délais plus longs) mais permet une meilleure évolution du code (par l'encapsulation et les hiérarchies de classe). Inversement, on peut produire très vite, en objet, du code très sale et parfaitement non maintenable (en multipliant les classes et les liens forts).

Francois
9  0 
Avatar de MiaowZedong
Membre extrêmement actif https://www.developpez.com
Le 21/08/2012 à 11:27
Citation Envoyé par psykokarl Voir le message

Disons qu'il n'est pas plus compliqué de chercher un bug dans un fichier de 1000 lignes que dans 10 fichiers de 100 lignes voir 100 fichiers de 10 lignes.
Je force le trait pour l'exemple mais c'est pour montrer que découper pour découper est contreproductif il faut qu'il y a de la pertinence derrière chaque découpage.
Un énorme +1

J'appelle ça le code mosaïque, parce que je commence à chercher ce que fait vraiment trois lignes de code, et je me retrouve avec des dizaines de fenêtres ouvertes qui font une mosaïque imbuvable à l'écran.....

C'est le code spaghetti 2.0, découpé en objets mais toujours aussi inmaintenable.
9  0 
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 04/08/2012 à 19:14
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.
9  1 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 06/08/2012 à 11:55
Citation Envoyé par Tryph Voir le message
(.../...)
pour moi, ceux qui affirment que l'objet, c'est juste mettre des données et des traitements dans une même classe pour résoudre un problème architectural n'ont tout simplement rien compris à l'objet. et quand on comprend pas grand chose à l'objet, effectivement on n'en voit pas l'intérêt.
(.../...)

La programmation, c'est "juste" aligner des instructions dans du code.....


Non, blague à part, j'ai dit ça parceque techniquement, ça se limite à ça. Evidemment, il y a tout l'aspect cognitif qui change du tout au tout. Ce qui a un impact profond sur la manière d'aborder le code, de concevoir l'architecture, en bref sur la manière de bosser, de penser, même. Mais, techniquement, j'insiste : ça n'est jamais qu'une limitation volontaire et structurante de l'accès aux modules contenant le code. Ce qui ne contredit pas l'impact que l'objet peut avoir sur la manière de concevoir le code.

J'ai fait(enfin, je n'ai pas fini, en raison d'un ordinateur cassé) un gestionnaire de règles de jeu de rôle en Java, et ça aurait été l'enfer de gérer tout ça en procédural. En objet, c'était bien plus efficace; une classe "element combattant", qui a 2 sous classes "personnage" et "monstre", avec juste ce qui faut dans la classe-mère pour gérer les interactions(i.e. les combats), et tout ce qui faut dans les sous-classes pour gérer les spécificités(un monstre n'a pas de compétence d'artisanat, un personnage n'a pas de probabilité d'apparition dans la forêt) était parfaitement adapté.

Mais ce que je fais au boulot n'a rien à voir. Le jeu de données change à chaque fois, et d'ailleurs on évite les bases de données au maximum, pour éviter les multiples jointures qui mettraient la machine à genoux. On fait des fichiers plats, avec juste ce qu'il faut dedans, et on les traite au kilomètre. Et ça marche parfaitement. En objet, il faudrait redéfinir une classe unique pour chaque traitement, et ça serait beaucoup plus couteux, pour un gain architectural plus que discutable. Redéfinir un fichier plat, en tous cas en Cobol, c'est méga simple : nom, position, longueur. On traite en suivant les specs, et ça marche.

ça n'est d'ailleurs sans doute pas un hasard si ici tout le transactionnel est en train de passer en Java(c'est fait à 99%), alors que les batches restent obstinément en cobol : le transactionnel se prête bien mieux à l'objet. Et y passe progressivement par pression évolutive.

Pour autant, je ne dis pas qu'on peut se permettre d'ignorer l'objet, même dans ma position : c'est un outil dans la boite, parmi les plus importants. J'aurais tendance à me méfier d'un menuisier sans marteau dans sa boite. Pour autant, il n'a pas besoin de marteau pour les éléments vissés. Moi, je fabrique des éléments vissés. Mais je sais clouer, juste, je ne le fais pas dans ma mission actuelle.
8  0