Discussion :

[tarikbenmerar]

Faut-il éviter de distraire les débutants avec l'orientée objet ?
Ou serait-il préférable de l'enseigner en premier ?



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

[CapFlow]

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.

[GeoTrouvePas]

Je pense également que l'apprentissage de la P.O.O. ne doit se faire qu'une fois qu'on est à l'aise, qu'on maîtrise et qu'on jongle parfaitement avec les méthodes "de base".

Il vaut mieux commencer par apprendre à marcher correctement avant d'apprendre à courir.......

[stardeath]

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

[Paul TOTH]

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 ?

[thelvin]

Or donc, la première question, c'est à quoi veut-on les former ?

Oui, mais dans tous les cas, le concept d'objet est trop éloigné du but à atteindre (du moins le concept d'objet actif, qui ne soit pas juste une structure qui ne fait rien.)

C'est du moins l'avis qui est décrit par les personnes présentes, et que je partage.
Essentiellement, c'est la différence entre apprendre une chose à la fois, et grosso-modo cinq choses à la fois.

[Invité]

Personnellement, je suis de ceux qui croient que commencer directement par l'OO n'est pas forcément une bonne chose, et que commencer par du procédural pour terminer par de l'OO est une bonne pédagogie.

Mais cette impression ne vaut strictement rien, et seuls les faits méritent d'être évoqués. Il faut savoir que dans le domaine de la pédagogie, de nombreuses recherches ont étés effectuées et qu'on arrive plus ou moins à savoir comment faire pour bien enseigner. Et dans le domaine de la programmation, on n’échappe pas à ce genre de choses. Ainsi, on sait plus ou moins ce qui rend un langage facile à apprendre et quelles sont les difficultés majeures : vous n'imaginez pas les difficultés que peuvent poser les structures de contrôle et l'assignement (oir ici pour les curieux : http://www.cl.cam.ac.uk/teaching/1011/R201/). Et concernant le débat OOP versus procédural, on a quelques éléments de débat venant d'études de psychologues sur le sujet.

J'ai effectué personnellement quelques recherches sur le sujet, et je suis tombé sur un document qui en parle un petit peu. Commencez à lire le pdf qui va suivre à partir de la page 142 : http://lib.tkk.fi/Diss/2012/isbn9789...9526046266.pdf, vous devriez avoir un paragraphe appelé "Objects are a bone of contention". Je vous laisse vous faire votre avis.

Au final, j'ai retenu que l'apprentissage précoce de l'OOP peut parfaitement marcher : ceux qui commencent par l'OOP n'ont pas de grosses différences de performances avec ceux qui ont commencés par du procédural, même si les difficultés rencontrées par ces deux types d'élèves ne sont pas les mêmes. Par contre, apprendre l'OOP en premier est plus complexe que du simple procédural (la notionnal machine d'un langage OOP est plus complexe que celle d'un langage procédural), ce qui est un désavantage. Personnellement, je suis d'avis de commencer par le procédural et d'expliquer l'OOP en faisant le lien avec les bases du procédural (et notamment en se basant sur la programmation modulaire). C'est le seul moyen que je vois pour apprendre l'OOP en utilisant les méthodes préconisées par la pédagogie explicite (garder une progression du simple au complexe, découpage du cours en petites unités notionnelles acquises en se basant sur les précédentes, pas de concepts "trop généraux" ou ambigus, etc).

[el_slapper]

Ou alors on prend l'approche Joel Spolsky : on les noie d'entrée sous les pointeurs et la recursion, et on ne garde que ceux qui respirent encore.

Mais, là encore, c'est une question de priorité : veut-on former les gens, ou choisir les plus aptes? Doit-on former tout le monde, et accepter que des gens pas tellement doués soient sur le marché, ou au contraire sabrer pour ne garder que les tous meilleurs, laisant une haine profonde du code à tous les autres? Il n'y a pas de réponse evidente à cette question.

Le posteur original, clairement, cherche à former tout le monde. Il parle d'enseigner la programmation à ses enfants - qu'ils en fassent leur métier ou non.

[Tryph]

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 ?

je suis partagé. je pense que c'est bien d'avoir un minimum de connaissance en algorithmie, c'est déjà plus simple à appréhender et puis de toute façon il faut bien maitriser ça pour remplir les méthode qu'on met dans nos chère classes.
après, faut bien avouer que certains ont du mal avec la philosophie objet et que même s'ils savent faire des classes, les instancier et les utiliser, ils le font à tort et à travers et qu'on se retrouve au final avec quelques chose de pas vraiment mieux structuré qu'avec du procédural.
alors l'un ou l'autre en premier, je sais pas trop, mais moi on m'a appris l'algo avant les principes objet et ce ne m'a pas parut impertinent.



Python est-il le langage idéal pour apprendre la programmation ?
Ou estimez-vous que d'autres langages remplissent mieux cette tâche ?

moi j'ai appris sur du java, ça ne m'a pas déplu.
j'ai un peu mal avec le python, je suis pas fan de la syntaxe, j'ai sans doute trop l'habitude de la syntaxe type C avec des accolades et des points virgules.
ceci dit, je pense que python peut être un bon langage d'apprentissage ne serait-ce que pour l'indentation obligatoire. car même au bout de quelques années de métier, y en qui ont du mal a indenter leur code correctement et je trouve ça particulièrement lourd de repasser derrière.



enfin, et un peu hors-sujet, faut pas croire que parce qu'on a fait ses premieres armes sur un langage de haut niveau, on est incapable de comprendre ce qu'est une libération de mémoire. les premières armes ne sont que les premières armes et chacun peut continuer à apprendre.
et puis quand j'étais en cours, même si presque tous les cours se faisaient avec du java, je me souviens très bien du prof en train de nous expliquer le fonctionnement du GC, les implications d'un passage de variables native ou encapsulée dans un objet, des histoires de pile et de tas, etc...
on n'est pas obligé de faire du C pour comprendre qu'une zone mémoire allouée doit être libérée, pour comprendre ce qu'est un pointeur ou pour appréhender les concepts de passages de variables par valeur ou par référence.
après, je suis entièrement d'accord pour dire que faire au moins un minimum de C pour mettre en pratique directement ces concepts est très utile, mais je ne pense pas que ça soit une obligation.

pour moi un développeur qui n'a aucune idée de ce qu'est un pointeur ou une libération de mémoire a eu un sérieux défaut d'attention pendant ses cours ou des profs complètement à la ramasse.

[Bousk]

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

Je suis d'accord avec toi, mais j'ai une approche inverse :
on commence par les concepts simples, sans parler mémoire etc
puis on s'enfonce pour "savoir comment ça marche"

J'ai en tous cas eu de meilleurs résultats ainsi
- tu montres ce qu'on peut faire, et ça parait pas trop compliqué
- tu les as intéressés
- tu montres comment ça marche avec un auditoire captivé

Dans l'ordre inverse
- holala j'ai rien compris
- "haaaaa un pointeur j'ai peur"
- plus personne ne te prête attention

En ce sens Python permet une bonne approche, pour ma part ce fut PHP3
Dans tous les cas un passage par du C me semble primordial, éventuellement par de l'assembleur pour les plus motivés/intéressés
Puis de l'objet, où Python peut encore être utilisé
Tout dépend des contextes qu'on veut montrer, ie on ne pourra pas mettre en relief les avantages de l'héritage multiple ou les dangers de l'héritage en diamant autre qu'en C++

[stardeath]

...

je suis d'accord qu'il faut des étapes dans la progression, c'est pour cela que je ne suggère que c/c++/assembleur, tu peux très bien faire du simple et du très compliqué sans changer de langage, donc sans se disperser vers des syntaxes/concepts différents.

je continuerai là dessus en préférant l'apprentissage du c++ plutôt que du c, toute la stl permet de se passer de l'apprentissage difficile (lol) des pointeurs (qui doivent au contraire être très rapidement maitrisés en c).

pour la poo, finalement ce n'est que commencer à responsabiliser son code, ne pas en faire assez tôt revient au même niveau que, amha, de ne pas écrire de commentaire dans le code : "j'ai pas le temps d'en écrire maintenant, je le ferai plus tard", sauf que le tard soit n'arrive pas, soit devient une corvée.

comme je l'ai dit dans une autre conversation, on est pas obligé d'enseigner tout ce qu'il y a de compliqué avec un langage comme c++, il y a moyen de faire des trucs simples quand même.

[gaiasson31]

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 ?

En effet je pense qu'il faut commencer par le commencement (ça va je me mouille pas trop ).
L'objet est certes une évolution qui a fait ses preuves dans le monde de la programmation mais vouloir faire une fusée en utilisant des supers moteurs nucléaires de la morkitu avant même de comprendre quelles sont les forces qui s'exercent sur un objet en vol s'avère quelque peu risqué...
L'objet permet de répondre de façon plus simple à certains problèmes mais cloisonne le raisonnement à vouloir catégoriser tous types de problème dans la case "à résoudre avec des objets" (et j'en suis la première victime ayant débuté avec l'objet...).

Python est-il le langage idéal pour apprendre la programmation ? Ou estimez-vous que d'autres langages remplissent mieux cette tâche ?

Pourquoi pas, mais je préfèrerai un langage plus carré qu'élégant, de type Pascal, même si le saint graal serait un langage fait maison par des profs, utilisé uniquement à des fins pédagogiques. La compréhension des concepts de programmation pour un débutant doit le plus possible transcender un langage en temps que tel, qui est empreint d'une certaine philosophie, sous peine de désintéresser certains débutants de la programmation à tord.

[Lupus Michaelis]

Et pourquoi une telle obsession de la programmation objet, ou orientée objet*?

Je pense que le choix de l'outil d'apprentissage et des paradigmes à enseigner doit dépendre de l'objectif. S'il est de former des programmeurs, commencer par du C et de l'assembleur est le meilleurs moyen d'apprendre à programmer. Cela permet de se concentrer sur quelques problèmes de base*: gestion de la mémoire, structuration, algorithmie.

Après quoi on peut commencer à parler de système, d'interaction l'OS et les autres processus. À partir de là, on peut discuter architecture, responsabilité entre les différentes briques (applications, bibliothèques, OS).

Ainsi le concept d'objet s'introduit de lui-même*: même sans utiliser un langage de programmation objet, n'importe quel logiciel est un objet qui interagi avec d'autres objets (et éventuellement un humain).

Et à partir de ces acquis, on peut introduire la programmation orienté objet. Évidement, le C++ est un langage de choix, mais il n'est pas question ici de maîtriser un langage*: il s'agit d'introduire un concept. Donc faire le tour de quelques langages et de montrer quelles solutions ont été apportées pour implémenter telle ou telle technique relative à la programmation objet. Du C++ au Java (ou C#), en passant par le Javascript, Ruby, Python, etc, sans oublier de mentionner qu'en C aussi, on peut programmer objet en tête.

Mais comme je l'ai dit en introduction, je crois qu'on se focalise trop sur la programmation orienté objets. Les langages fonctionnels sont certainement les plus grand perdant dans l'histoire. D'accord, C++ supporte ce paradigme, mais il est souvent occulté au profit des classes omniscientes.

Maintenant, pour ceux qui ne seront jamais amenés à programmer à plein temps, je pense qu'on peut faire une approche plus légère. Mais je serais bien en peine de leur proposer un programme (de cours).

(PS*: les espaces insécables semblent remplacées)

[anthyme]

J'ai expliquer l'objet, la théorie, les tenants et les aboutissants, les interets à l'utiliser à mon frère qui est en école d'info au début de son cursus.

Ensuite je l'ai laisser suivre ses cours en lui disant "essai de penser comment tu pourrais structurer ce que tu fais en objets".

Il fait ensuite du lisp, caml et autres langages d'apprentissage sans objets.
2 ans plus tard il passe au c# et a une bien meilleure compréhension du modèle objet, de quand et comment extraire du code dans une classe, partage de code etc. Il arrive aussi à être très critique sur des chose codé "n'importe comment".

Je penses qu'il y a une histoire d'habitude dans tout ça, mettez quelqu'un trop a l'aise dans le procédurale et il ne voudra même pas faire de l'objet pensant que ca marche très bien comme ça et il va mettre du temps a acquérir ces notions malgrès lui.

A mon avis comme on ne fais pas de procédurale sans avoir fait un peu de théorie d'algorithmique on ne devrait pas développement de logiciel sans avoir appris de la théorie objet.

[Thiht]

En un mot il propose d'apprendre la partie algorithmique avant d'apprendre la partie architecture, je vois rien de révolutionnaire à ça. Comme il ne parle pas d'algorithmique mais directement d'un langage, on sous-entend le procédural.
Ce qui s'est toujours fait en somme (du moins je ne connais personne qui fait de l'OO AVANT de faire soit de l'algo pure, soit du procédural, et je vois simplement pas comment ce serait possible).

Pour python comme premier langage je suis pas particulièrement d'accord, tout langage pouvant être utilisé comme procédural est bon pour commencer. A titre personnel j'aurais pas tendance à conseiller python, y a quelques éléments de syntaxe dans les appels de fonctions que je trouvais carrément contre-intuitifs (des fonctions à utiliser soit en procédural, soit en tant que méthodes sur un objet, soit au choix selon le contexte, je trouve ça dégueulasse).

[I_believe_in_code]

Il fait ensuite du lisp, caml et autres langages d'apprentissage sans objets.

Euh... Common Lisp et Ocaml (au moins eux) ont tout ce qu'il faut pour faire de la programmation objet. CLOS est même un excellent choix pédagogique pour enseigner les concepts de la POO à des élèves : plus puissant que Python (j'ai toujours trouvé que Python c'était un centième de Lisp en pourri), moins bizarre que C++ (avec ses fonctions amies et autres tares) et surtout moins bête que le "tout objet" Java qui oblige à créer une classe juste pour écrire un main, ce qui n'a bien évidemment même pas de sens.

[BenoitM]

Euh... Common Lisp et Ocaml (au moins eux) ont tout ce qu'il faut pour faire de la programmation objet. CLOS est même un excellent choix pédagogique pour enseigner les concepts de la POO à des élèves : plus puissant que Python (j'ai toujours trouvé que Python c'était un centième de Lisp en pourri), moins bizarre que C++ (avec ses fonctions amies et autres tares) et surtout moins bête que le "tout objet" Java qui oblige à créer une classe juste pour écrire un main, ce qui n'a bien évidemment même pas de sens.

Java ne vous oblige a rien part contre c'est vrai qu'en POO il est mieux de créer une main plutot que de devoir passer à chacune de vous méthodes 5 doigts, et de vous rendre compte ensuite qu'il fallait donner les 5 doigts et 3 phalanges respectives
On dirait que personne n'a eu le cas où il devait passer à la méthode X l'arguement Y,et de devoir changer 3 fonctions pour pouvoir passer cet argument la fonction X et donc changer tout les appels de ces 3 fonctions

[Bousk]

Pourquoi assimiler l'objet au C++ et le dégager du C ?
On peut faire du code objet en C, avec de simples structures et des méthodes qui prennent ces structures en paramètres.
Et c'est ce que j'essaye de transmettre pour ma part en "cours de C", avec des exemples simples : on a le choix entre une fonction à 4 paramètres pour représenter une personne (par son nom, prenom, age, sexe) ou une structure qu'on appelera Personne qui contiendra toutes ces informations. Généralement ils ne voient pas l'intérêt de prime abord. On décide de rajouter 1 paramètre et ils le voient déjà mieux. On leur inclut une erreur qui utilise l'age de Personne 2 au lieu de la Personne 1 en paramètre et ils y voient plus clair encore.

La plupart des étudiants qui disent "ne rien comprendre à l'objet" en ont même déjà utilisé : FILE*.

Le problème que je vois pour ma part, c'est le même que souvent : un à priori qui fait qu'ils se braquent et ne font pas l'effort d'apprentissage.

Après oui, quand on va plus en avant on voit les mot-clé virtual, héritage etc, mais ce n'est qu'après. Et après on se rend compte qu'ils sont bien pratiques également .
Mais on ne va bien entendu pas commencer un cours de programmation objet en C++ par un cas d'héritage en diamant..

[BenoitM]

Pourquoi assimiler l'objet au C++ et le dégager du C ?
On peut faire du code objet en C, avec de simples structures et des méthodes qui prennent ces structures en paramètres.
Et c'est ce que j'essaye de transmettre pour ma part en "cours de C", avec des exemples simples : on a le choix entre une fonction à 4 paramètres pour représenter une personne (par son nom, prenom, age, sexe) ou une structure qu'on appelera Personne qui contiendra toutes ces informations. Généralement ils ne voient pas l'intérêt de prime abord. On décide de rajouter 1 paramètre et ils le voient déjà mieux. On leur inclut une erreur qui utilise l'age de Personne 2 au lieu de la Personne 1 en paramètre et ils y voient plus clair encore.

Euh simplement parce que la POO ce n'est pas des structure
La POO c'est aussi qu'une classe contient des méthodes contrairement aux structures
Que vu que ces méthodes sont liées aux objets il y a la notion d'héritage, vu la notion d'héritage on a fait la notion d'interface. Que la notion d'objet et de méthode liées aux objets on a crée des méthodes statiques.
Qu'on a créer la protection des membres de structures (private public protected) bref oui en C tu as des structures mais C ce n'est pas de la POO
(Certes si tu connais la POO , tu feras en general mieux tes découpes en C mais ca n'a rien avoir avec de la POO)

Pour conduire une moto il me faut le code de la route, si je conduis une voiture je connais le code de la route (entk normalement) ce n'est pas pour ca que je sais conduire une moto (et vice-versa c'est pas parce que je suis un bon programmeur en POO que je serai un bon programmeur en C (même si ca va m'aider))

[Emmanuel Colomb]

Pourquoi assimiler l'objet au C++ et le dégager du C ?
On peut faire du code objet en C, avec de simples structures et des méthodes qui prennent ces structures en paramètres.
Et c'est ce que j'essaye de transmettre pour ma part en "cours de C", avec des exemples simples : on a le choix entre une fonction à 4 paramètres pour représenter une personne (par son nom, prenom, age, sexe) ou une structure qu'on appelera Personne qui contiendra toutes ces informations. Généralement ils ne voient pas l'intérêt de prime abord. On décide de rajouter 1 paramètre et ils le voient déjà mieux. On leur inclut une erreur qui utilise l'age de Personne 2 au lieu de la Personne 1 en paramètre et ils y voient plus clair encore.

La plupart des étudiants qui disent "ne rien comprendre à l'objet" en ont même déjà utilisé : FILE*.

Le problème que je vois pour ma part, c'est le même que souvent : un à priori qui fait qu'ils se braquent et ne font pas l'effort d'apprentissage.

Après oui, quand on va plus en avant on voit les mot-clé virtual, héritage etc, mais ce n'est qu'après. Et après on se rend compte qu'ils sont bien pratiques également .
Mais on ne va bien entendu pas commencer un cours de programmation objet en C++ par un cas d'héritage en diamant..

Ah j'adore ce type d'enseignement :
- commencer par présenter un cas simple... qui fonctionne car il est simple (fonction avec 4 paramètres)
- puis faire comprendre que ça ne peut pas fonctionner correctement dans un cas plus complexe (6, 7... 100 paramètres ?)
- et d'introduire une nouvelle notion qui apporte une solution (utilisation de structure... voir même de structure de structure)

Je pense que c'est le meilleur moyen de faire prendre conscience petit à petit de l'intérêt de finalement passer du tout procédural et non structuré, à de la POO; et puis ensuite de faire comprendre tout l'intérêt d'utiliser le C++ plutôt que le C.

Un gros +1 !

Une 'bonne' POO en C++ apporte des gains énormes par rapport à une bonne PP en C (ne serait-ce que pour les exceptions). Et bien souvent un programmeur débutant devra directement construire ou maintenir des programmes de type POO.
Pour comprendre tout l'intérêt de la POO, il faut avoir appris, mieux avoir pratiqué, la PP.
Pour éviter tous les pièges de la POO, c'est une autre histoire