Discussion :

[Aldian]

Quand j'étais en collège/lycée, j'ai appris le basic, ça m'a plutot bien réussit, car après quelques usines à gaz j'ai appris à faire preuve de rigueur en codant.

Ensuite en école j'ai d'abord appris le C puis le java, et je trouve que c'est très bien comme ça, tout simplement parce que le C permet d'apprendre ce qui se passe vraiment dans l'ordinateur, et le jour où l'on va créer un logiciel destiné à subir une forte charge, on n'est pas supris d'être limité par les accès disque, les dépassement de pile, les pools qui se remplissent trop vite ou tout autre effet lié aux limites physiques des systèmes parce qu'on a les outils pour imaginer comment ça se traduit au niveau du système.

C'est pour cette raison que je pense pour ma part qu'il ne faut pas apprendre l'objet aux débutants, à moins d'être certain qu'ils ne seront jamais confrontés à la problématique que je viens d'évoquer. D'autant plus que l'objet que l'on apprend au débutant est souvent extrêmement dépouillé, il leur faut beaucoup de temps pour prendre la mesure de tous les mécanismes et avoir assez de recul.

Avec le temps, lorsqu'ils commenceront à élaborer des logiciels suffisamment gros pour qu'ils éprouvent le besoin de structurer le code en regroupant les fonctions traitant d'un même type de structure, la nécessité d'apprendre l'objet s'imposera d'elle même, et ils en comprendront bien mieux l'intérêt que des gens qui n'ont jamais codé et à qui cette philosophie de pensée peut paraitre tordue si on leur fait prendre trop de raccourcis.

[MiaowZedong]

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.

Sans compter que la programmation fonctionelle a débouché sur un certain nombre de projets très réussis, comme—par exemple—l'algo MapReduce de Google et le système DARTS de l'armée Américaine. Juste parce que ce n'est pas conforme aux buzzwords actuels, ça ne veut pas dire que ça ne sert à rien

P.S. on peut très bien implémenter les concepts objets en C, il existe d'ailleurs des frameworks objet en C pour éviter de devoir réinventer la roue.

[BenoitM]

Sans compter que la programmation fonctionelle a débouché sur un certain nombre de projets très réussis, comme—par exemple—l'algo MapReduce de Google et le système DARTS de l'armée Américaine. Juste parce que ce n'est pas conforme aux buzzwords actuels, ça ne veut pas dire que ça ne sert à rien

P.S. on peut très bien implémenter les concepts objets en C, il existe d'ailleurs des frameworks objet en C pour éviter de devoir réinventer la roue.

Vu que je me suis surement pris le -1 part vous pouvez-vous me reiseigneur sur ces framework? Qu'on puisse tenter d'implémenter des concepts objets à un langage procédure, je le conçois qu'on puisse transformer un langage procedure en language objet j'ai un doute (surtout via un framework)

De plus si via des framework on s'amuse a mettre des éléments de POO dans un langage procédurale, ca doit bien signifier que la POO peut apporter un plus :p

[MiaowZedong]

Vu que je me suis surement pris le -1 part vous pouvez-vous me reiseigneur sur ces framework? Qu'on puisse tenter d'implémenter des concepts objets à un langage procédure, je le conçois qu'on puisse transformer un langage procedure en language objet j'ai un doute (surtout via un framework)

De plus si via des framework on s'amuse a mettre des éléments de POO dans un langage procédurale, ca doit bien signifier que la POO peut apporter un plus :p

Le plus connu est sans doute GObject utilisé par le projet GNOME Mais vois aussi par exemple http://daifukkat.su/wiki/index.php/SOO qui est un système beaucoup plus basique.

N'oublions pas non plus que la quasi-totalité des languages objets sont implementés avec des compilateurs écrits en C

La POO n'est bien sûr pas sans intérêt, mais c'est une façon de coder qui n'est pas adaptée à tout et ne doit pas remplacer dans l'enseignement les bases que sont l'algorithmique, les types, les pointeurs....

P.S. le vote -1, en fait, ce n'est pas moi

[psykokarl]

Qu'on puisse tenter d'implémenter des concepts objets à un langage procédure, je le conçois qu'on puisse transformer un langage procedure en language objet j'ai un doute (surtout via un framework)

De plus si via des framework on s'amuse a mettre des éléments de POO dans un langage procédurale, ca doit bien signifier que la POO peut apporter un plus :p

Une structure peut stocker tout type de donnés dont... des adresses de fonctions. Moyennant un jeux de déclaration et d'affectation de base tu peux avoir une notation du type:

maStructure->maMethode(/*parametre*/);

Mais c'est une façon de représenter le code. si on crée une fonction qui prend une structure de données en paramètre on a:

maMethode(maStructure, /*parametre*/);

Des exemples foisonnent sur le net...
En fait la POO est un sous ensemble des concepts mis au point avec des langages procéduraux. C'est plus une manière d'organiser le code parmi d'autres.

Le cœur du métier reste de de savoir comment faire fonctionner le code et non comment l'organiser. La POO est utile dans la mesure ou l'on dispose d'un modèle d'organisation efficace sans avoir à gérer structures et pointeurs.
En revanche dès que l'on commence triturer l'esprit pour savoir comment rendre son code performant et/ou plus lisible avec de l'objet, les perd les bénéfices les bénéfices qu'apportent la POO.

[gl]

pouvez-vous me reiseigneur sur ces framework? Qu'on puisse tenter d'implémenter des concepts objets à un langage procédure, je le conçois qu'on puisse transformer un langage procedure en language objet j'ai un doute (surtout via un framework)

COS

[mek-in-gold]

Je suis de ceux qui pensent qu'il faut commencer par la POO.

Je pense qu'au contraire il faut commencer par savoir comment Architecturer et structurer et cela en dehors du principe de coder.

D'abord on fera de la théorie avec des exemples qui ne sont pas du code puisque le but est ici d'apprendre à coder. Après on commence à coder en se servant des bons Design Pattern.

La POO est un concept assez simple si on l'apprend dans un concept général. Beaucoup de langages ne sont qu'orienté objet et ne permettent pas la procédurale. Si la procédurale était un principe obligatoire alors personne ne pourrait commencer par des langages dits seulement objet.

La procédurale est un concept ancien et démodé, il a servit un temps mais les techniques de programmation ont évolué.

Apprendre à programmer doit être quelque chose de constamment évolutif. C'est comme gérer une équipe et lui demander d'exécuter des tâches. Elle sera plus efficace avec une bonne structure réfléchie.

On évolue toujours sur la façon de gérer une équipé et on adapte également toujours selon les besoins.

On n'apprend pas de vieilles méthodes de travail sinon elles restent ancrées et le passage à d'autres méthodes fait naitre la question du 'Pourquoi changer'. La personne n'aura pas forcément envie d'évoluer car elle se sent bien dans son contexte actuel ou elle à ses repères.

Un bon développeur doit être évolutif et penser d'abord à la structure puis après à l'alimenter. Un bon code bien structuré pourra toujours évoluer. Sinon cela s'apparente à une chimère.

Je pense qu'il n'y a pas de meilleur langage plus qu'un autre c'est la façon de l'apprendre et de savoir l'utiliser.

Les langages basés sur la POO reprennent eux-mêmes une architecture et des concept assez communs mis en place par la POO. Ainsi que ce soit en C# , Java ou PHP on retrouve plusieurs concepts de structure et de design pattern communs. Ces similitudes permettent le portage d'un code d'un langage à un autre langage de manière plus simple. On doit bien sur affronter quelque différences techniques mais on n'a pas à repenser autant la structure.

La POO associée à la POA communément appelé programmation orientée aspect, peut aussi faire l'objet d'un certain présentéisme d'un point de vue organisation.

[Sorentao]

Faut-il, d'après vous, éviter de distraire les débutants avec la programmation orientée objet ?
Comme beaucoup d'avis postés précédemment, la POO n'est pas l'idéal pour débuter.

Python est-il le langage idéal pour apprendre la programmation ?
C'est un bon langage pour commencer, notamment de par sa syntaxe très axée pseudo-code , mais il y a d'après moi d'autres alternatives toutes aussi valables qu'il est difficile de le qualifier d'idéal. D'expérience, j'ai constaté que le C est une alternative viable, de par son approche bas-niveau initiant au procédural, à la gestion de mémoire, à l'algorithmique qui lui est liée, etc.

Sur le fond je suis d'accord pour dire que l'idéal n'est pas de débuter l'apprentissage par la POO. Il y a cependant un point sur lequel je le suis beaucoup moins :

l'orienté objet force le programmeur « à réfléchir non pas en terme de problème et de solution, mais en terme d'architecture »

C'est absolument le cas. Mais est-ce un mal aussi prononcé qu'il est présenté ici ?
Dans un cadre professionnel, le même code est souvent pris et repris par plusieurs développeurs au fil du temps, pour des raisons d'évolution ou de maintenance. En partant de ce principe, il me parait justifié de prendre au moins autant de temps à réfléchir sur son architecture que sur la solution du produit en tant que tel.

Hormis ce détail, je suis totalement d'accord avec l'avis de James Hague

[beegees]

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.

[Paul TOTH]

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.

[beegees]

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

[Paul TOTH]

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.

[jnspunk]

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.

[chaplin]

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

[jnspunk]

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

[jnspunk]

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

[transgohan]

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

[jnspunk]

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!

[ec]

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.

[chaplin]

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.