Discussion :

[Invité]

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

[Invité]

Pour en revenir au sujet de départ : James Hagues a raison. On a visiblement quelques études scientifiques sur le sujet qui valident ce qu'il dit. Du moins, c'est ce qui est écrit à la page 7 de ce .pdf : http://www.humantechnology.jyu.fi/ar...-kuittinen.pdf.

Détienne (1997) notes that when novices design OO programs, the activity of finding classes consumes their attention; they think about functionnality only late in design activity. Ebrahimi and schweikert (Empirical study of novice programming with plans and objects- 2006) found that student have problems in understanding object orientation and integrating OO concepts into problem solving. Students tend to spend more time trying to understand objects and less time on problem solving

Je crois qu'on ne peut pas faire plus clair. Dommage que j'ai pas accès aux études citées, j'aurais bien aimé les lire.

[psykokarl]

Amen !

J'ajouterai qu'avec ce "formalisme" il est possible de factoriser (un autre terme mathématique) le code pour avoir une structure d'ensemble se rapprochant de la POO ou d'un autre paradigme.
En revanche quelqu'un formé uniquement à l'OO n'aura pas ce formalisme pour casser ces structures quand cela s'avère nécessaire.

Quoi qu'il en soit le procédural fait partie du tronc commun.
Ceux qui auront de bonne base en procédural comprendront le passage naturel du procédural à l'objet.
Ceux qui auront commencé par l'objet ne feront pas forcément le rapprochement entre les deux. Ils risquent de voir le procédural comme un "truc" en plus pour quand l'objet ne marche plus.

[el_slapper]

Je suis coboliste de base, et je sais faire de l'objet. Mais je me suis auto-formé. Je ne sais pas, donc, si je suis représentatif.

MAIS

Pour moi, l'objet n'est qu'une ecapsulation standardisée du procédural. D'un point de vue de ce que fait réellement le programme, une classe, c'est un dépot de code - dont les méthodes d'appel sont limitées par le paradigme objet.

Ce qui est parfait là ou le paradigme s'applique bien. Moi, je fais, entre autres, du cobol(merci de ranger les insultes, elles ne font pas avancer le débat) en bancaire, et mes spécifications sont en général une longue litanie d'opérations simples, la complexité étant dans le nombre d'opération et dans leur manque total de lien entre elles.

C'est typiquement un domaine ou l'objet, dans la plupart des cas, n'apporte rien. Je prends la donnée, je la torture conformément aux specs, et je la restitue. Puis je prends la donnée suivante, je la..... vous avez compris. Le manque de fonctions définies par l'utilisateur est nettement plus pénalisant que le manque d'objet(enfin, ils existent, mais sont à peu près inutilisables, car très mal conçus).

Il arrive que je souffre de l'absence d'objets, sur certains algorithmes précis. Mais c'est un cas fort rare. D'autres métiers auront d'autres retours.

Enfin, je suis d'accord avec mewtow. Une conception tout objet, c'est beaucoup de travail. Qui peut être fortement utile dans certains cas, et pas du tout dans d'autres. Ici, les abaques de développement donnent un cout moitié moindre pour les développement cobol par rapport à java. Ca n'est pas un hasard. L'objet a un cout, et il ne faut le payer que quand on peut espérer le rentabiliser.

[chaplin]

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

[SLiM_ViNCe]

Je ne comprends pas le sujet. Il y a plusieurs paradigmes de développement dont l'orienté objet mais je ne comprends pas qu'il n'y ait que deux choix : soit apprendre QUE ça, soit ne pas du tout l'apprendre. On commence pour la plupart avec du procédural/impératif type Pascal pour finir sur de l'objet.

La gestion de la mémoire n'a rien à voir avec tel ou tel paradigme, c'est une constante de l'infrastructure. Les deux doivent donc être enseignés, de préférence la gestion de la mémoire précédemment mais pas nécessairement puisque tant que la formation n'est pas achevée, on n'est pas sensé être des cadors du dév... Et puis la gestion de la mémoire, c'est pas juste du malloc ou autres primitives du C... C'est aussi des algorithmes de recherche de données, de pagination, etc (types SGBD et autres). Bref, je trouve la vision "gestion de mémoire pour un dév => C/malloc" beaucoup trop réductrice. La mémoire c'est pas juste la taille d'un objet et la suppression de celui-ci quand il est inutilisé en RAM... Il se passe beaucoup d'autres choses qui méritent elles-aussi de la considération même pour des dévs...

Peu importe l'ordre d'apprentissage finalement AMHA, ce qui compte, c'est d'être conscient de l’existence de ces concepts. Apprendre le procédural, l'impératif ou l'objet en premier, c'est une question qui n'a pas réponse certaine mais il est certain qu'il faut tous les apprendre... Puisque ce sont des approches différentes permettant de résoudre les problèmes...

[Tryph]

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.

voila quelqu'un qui, de mon point de vue, a réellement compris le concept de POO.
la philosophie objet, c'est avant tout de faire un modéle de la réalité et donc de reproduire (dans une certaine mesure) les objets réels et leurs interactions.

il me semble que pour un cerveau humain, il est beaucoup plus simple d'appréhender un chat comme une entité à part entière qui possède des caractéristiques (couleur, taille, nombre de pattes...) et des comportements (marcher, manger, dormir...).

et c'est juste ça l'objet... représenter la réalité (avec un certain degré de précision à adapter en fonction du projet) autant que nécessaire/possible.

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.

bon par contre j'irai pas jusqu'à dire qu'il faut apprendre l'objet en premier (c'est pas ce que j'ai fait). mais apparemment faut mieux former les gens aux concepts vraiment basiques de l'objet par ce que c'est clair que c'est loin d'être acquis pour un grand nombre de devs.

[ec]

Pour moi, l'objet n'est qu'une encapsulation standardisée du procédural.

Oui chaque objet obéit à du procédural. Le procédural est toujours relatif à un objet, pensé comme tel ou implicite. L'objet est conçu comme pouvant réagir dans certaines situations.

Je prends la donnée, je la torture conformément aux specs, et je la restitue. Puis je prends la donnée suivante, je la..... vous avez compris.

Ici, d'un point de vue conceptuel, l'enregistrement de base de données est un objet sans méthodes propres, mais avec quelques propriétés (numérique, texte, date, etc...). Le module de traitement est un objet qui manipule des objets avec ses méthodes.

L'approche objet est descriptive, elle se veut à l'image de l’organisation du SI. Le procédural est introspectif : comment fait tel objet dans telle situation qu'il "perçoit" grâce à ses capteurs appropriés ... et qui peut être une manipulation d'autres objets.

J
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

Il ne faut confondre l'hésitation de la démarche avec la structure de fait. Dans cet exemple, il s'agissait d'ajouter une méthode à l'objet charrette. Il y avait bien un cahier des charges : faire avancer un véhicule par une force interne plutôt que par une force externe. Ensuite on ajouta des freins... un volant...

La POO ne consiste pas à livrer une structure rigide, mais précisément à permettre une évolution plus facile à intégrer.
Dans les faits il s'agit de découper le procédural en éléments micro-procéduraux.... auquel on peut ajouter d'autres éléments micro-procéduraux... "C'est exactement pareil avec un programme un tant soit peu complexe."

Le IF THEN ELSE est un objet, une boucle aussi. Tout objet se caractérise par un nom. Tout ce qui est nommé par l'homme est un objet, c'est à dire quelque chose sur lequel l'intelligence peut fonctionner et trouver une solution à une question posée relative à cet objet, différencié par son nom et ses propriétés particulières

[niarkyzator]

Le titre est quand même bête.

Sauf erreure de ma part, la programmation objet c'est quand meme l'immense majorité du développement de nos jours.

Si la majorité des développeurs font de la POO, alors l'objectif des études d'informatique c'est d'apprendre la POO (entre autres choses).

Or le principe de la "distraction" (en partant de principe que le titre ne parlait pas de distraction au sens récréatif) c'est de détourner quelqu'un de son objectif initial.

C'est comme dire "le missile à été distrait par un avion ennemi et l'a détruit", ça n'a pas de sens.

[el_slapper]

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

[Paul TOTH]

voila quelqu'un qui, de mon point de vue, a réellement compris le concept de POO.
la philosophie objet, c'est avant tout de faire un modéle de la réalité et donc de reproduire (dans une certaine mesure) les objets réels et leurs interactions.

il me semble que pour un cerveau humain, il est beaucoup plus simple d'appréhender un chat comme une entité à part entière qui possède des caractéristiques (couleur, taille, nombre de pattes...) et des comportements (marcher, manger, dormir...).

je ne suis absolument pas d'accord, il n'y a aucun rapport entre "programmation orienté objet" et "objet de la vie courante". Depuis quand un chat est un quadrupède qui miaule et un chien un quadrupède qui aboie ? L'humain n'est alors qu'un quadrupède debout ?! Si l'on peut tenter de décrire l'environnement humain en termes orientés objets, il n'ont absolument rien de naturel. D'ailleurs, tu termines par un "c'est loin d'être acquis" !

reproduire des objets réels ? je ne connais pas beaucoup d'objet réel polymorphe ou abstrait ! ou de technicien qui sache réparer tout ce qui a un moteur et quatre roues sans se préoccuper du reste.

et c'est juste ça l'objet... représenter la réalité (avec un certain degré de précision à adapter en fonction du projet) autant que nécessaire/possible.

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.

en même temps je ne fais pas de la philo mais de la programmation : l'objet n'est pas une finalité, c'est un moyen.

bon par contre j'irai pas jusqu'à dire qu'il faut apprendre l'objet en premier (c'est pas ce que j'ai fait). mais apparemment faut mieux former les gens aux concepts vraiment basiques de l'objet par ce que c'est clair que c'est loin d'être acquis pour un grand nombre de devs.

[Invité]

La philosophie objet, c'est avant tout de faire un modéle de la réalité et donc de reproduire (dans une certaine mesure) les objets réels et leurs interactions.

On est d'accord, mais du coup la bonne question c'est: est-ce une bonne idée pour faire des programmes qui fonctionnent, évoluent, et ne sont pas trop durs à maintenir?

Un avion ne ressemble pas à un oiseau, et pourtant vole. Les bateaux à voile n'imitent pas grand chose de naturel, et pourtant naviguent. La "philosophie objet" (par opposition au paradigme, qui est juste une bonne pratique d'organisation du code et des données) part de l'idée qu'en modélisant la réalité, on l'appréhende mieux. Ce n'est pas si évident que cela.

Et que se passe-t-il quand la modélisation n'est pas bonne? je pose la question, parce que presque toujours, les modèles objets de la réalité représentent celle ci au travers de concepts plus ou moins fumeux (les design patterns), ou inspirés par d'autres projets, sur d'autres secteurs (cf tous les projets conçus en SSII). Peut on espérer une bonne description de la réalité venant d'un "architecte système" qui ne connait pas le sujet, et en discute avec des utilisateurs souvent le nez dans le guidon? Et si la description n'est pas bonne, comme espérer que le mauvais modèle de la réalité donne de bons résultats?

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.

Non, c'est une vision limitée de la POO comme paradigme (truc de codeur si tu veux), par opposition à sa vision comme philosophie et théorie des modèles.

Dans cet exemple, il s'agissait d'ajouter une méthode à l'objet charrette. Il y avait bien un cahier des charges : faire avancer un véhicule par une force interne plutôt que par une force externe. Ensuite on ajouta des freins... un volant...

Tu crois vraiment que quelqu'un a écrit un cahier des charges de la voiture, de l'avion, du téléphone ou de l'ampoule?

Dans tous ces cas, on a une idée initiale,"on pourrait utiliser la force motrice de la vapeur", puis des essais et erreurs, qui finissent pas se stabiliser. C'est à ce moment, et à ce moment seulement, que les "théoriciens objet" peuvent arriver et découvrir les classes de base, les méthodes, et les propriétés.

C'est exactement pareil pour un logiciel un tant soit peu innovant. L'idée initiale qu'on se fait des "objets de base" est presque toujours fausse (ca tient en partie au fait que beaucoup d'architectes ont une expérience très limitée de la programmation, et parfois un bagage scientifique réduit, mais aussi au fait que l'expérience, sur un projet innovant, est souvent plus importante que l'analyse initiale).

Pour moi, le paradigme objet est plus une méthode permettant d'améliorer le code que de le concevoir.

Francois

[chaplin]

Dans tous ces cas, on a une idée initiale,"on pourrait utiliser la force motrice de la vapeur", puis des essais et erreurs, qui finissent pas se stabiliser. C'est à ce moment, et à ce moment seulement, que les "théoriciens objet" peuvent arriver et découvrir les classes de base, les méthodes, et les propriétés.

C'est exactement pareil pour un logiciel un tant soit peu innovant. L'idée initiale qu'on se fait des "objets de base" est presque toujours fausse (ca tient en partie au fait que beaucoup d'architectes ont une expérience très limitée de la programmation, et parfois un bagage scientifique réduit, mais aussi au fait que l'expérience, sur un projet innovant, est souvent plus importante que l'analyse initiale).

Pour moi, le paradigme objet est plus une méthode permettant d'améliorer le code que de le concevoir.

Francois

Bravo! ça me coûte un mois non payé pour avoir osé utiliser cette approche et m'apercevoir que je ne suis pas seul à le penser. J'avais tellement le nez dans le guidon que j'ai fait appel à un mathématicien pour prendre du recul, et ce dernier de me répondre, "ne m'emmerde pas avec la technique".

[DevTroglodyte]

Personnellement, j'ai pu voir les "ravages" d'un enseignement orienté POO dès le premier cours, sans entrer dans les explications bas niveau, pour me rendre compte qu'il faut une approche plus orientée procédurale et bas niveau pour appréhender correctement le développement.

il FAUT enseigner aux élèves comment fonctionne une machine, ce que sont les pointeurs (bé oui, on manipule que ça en java/c#), etc. Personnellement, j'ai commencé par du Pascal, puis C/C++ et asm, et je n'ai pas eu de soucis à me mettre à la POO quand les cours ont porté dessus. C'est assez désolant de voir la quantité de développeurs (en devenir ou non) qui n'ont pas la moindre idée de comment est géré leur objet par la vm. Qui n'ont pas non plus la moindre idée de comment fonctionne leur PC, d'ailleurs.

Pour moi, la POO ne doit s'apprendre qu'apres avoir eu un enseignement sur le fonctionnement d'un PC, le fonctionnement des allocations lors de l'exécution d'un programme, et de l'algo. (et le fonctionnement d'une VM, aussi...)

[Tryph]

en même temps je ne fais pas de la philo mais de la programmation : l'objet n'est pas une finalité, c'est un moyen.

il ne s'agit pas de faire de la philosophie mais de mettre en application des "bonnes pratiques" et de se servir au mieux des possibilités que nous apportent les langages orientés objet.

quand on fait une bibliothèque de fonction procédurales, on ne met pas tout et n'importe quoi ensemble et on organise ça de façon logique ou au moins pertinente...
suffit pas de faire des bibliothèques avec un bordel monstre à l'intérieur et sans organisation pour se dire "c'est du bon boulot modulaire".

bah l'objet c'est pareil, suffit pas de savoir déclarer une classe pour savoir faire de la POO.

après libre à chacun de se foutre ou non des pratiques reconnues... y a moyen de faire des devs qui fonctionnent sans ça... chacun son truc.

[Paul TOTH]

il ne s'agit pas de faire de la philosophie mais de mettre en application des "bonnes pratiques" et de se servir au mieux des possibilités que nous apportent les langages orientés objet.

quand on fait une bibliothèque de fonction procédurales, on ne met pas tout et n'importe quoi ensemble et on organise ça de façon logique ou au moins pertinente...
suffit pas de faire des bibliothèques avec un bordel monstre à l'intérieur et sans organisation pour se dire "c'est du bon boulot modulaire".

bah l'objet c'est pareil, suffit pas de savoir déclarer une classe pour savoir faire de la POO.

après libre à chacun de se foutre ou non des pratiques reconnues... y a moyen de faire des devs qui fonctionnent sans ça... chacun son truc.

mais qui a dit qu'il fallait coder l'objet n'importe comment ? pas plus l'objet que le procédural d'ailleurs. Et ce n'est pas parce qu'on sait qu'un objet n'est techniquement rien d'autre qu'une structure avec des pointeurs qu'on fait n'importe quoi avec. Ce n'est pas parce que tu sais démonter un carburateur qu'il faut te retirer le permis de conduire !

[ec]

Tu crois vraiment que quelqu'un a écrit un cahier des charges de la voiture, de l'avion, du téléphone ou de l'ampoule?

Francois

Je ne suis pas formaliste au point de me demander s'il y a eu un cahier des charges concret. Un cahier des charges, tel que tu l'entends, n'est que la traduction par écrit d'un ensemble de directives de développement. Oserais-tu dire aujourd'hui qu'il n'y a pas de cahier des charges parce qu'il est écrit sous forme de fichier électronique de traitement de texte ? C'est pourtant ce qu'on t'aurait répondu en 1970. Dans le cas de la voiture ou de l'ampoule, le cahier des charge était clairement élaboré et mémorisé au minimum dans la tête de ceux qui poursuivaient cet objectif.... peu importe le support de l'idée. Ce n'est quand même pas à un programmeur qu'on va expliquer la réalité du virtuel ! Notre premier outil de travail c'est notre tête.

[Côme]

Procéder par étape ne peut pas faire de mal, mais il serait dommage à mon sens de réfréner des envies. Pourquoi ne pas imaginer qu’un programmeur puisse rapidement se trouver un gout pour ce style de programmation ? Quelqu’un maitrisant parfaitement l’objet s’accommodera très bien, il me semble, d’une programmation procédurale. L’inverse est moins évident.

Python me semble être un bon langage pour apprendre les deux styles de programmation même si personnellement mon choix s’est porté sur Ruby.
En revanche, il me semble assez difficile de résister à l’objet bien longtemps avec ces deux langages. Peut-être est-ce plus simple avec Python, qui me semble plus « multiparadigme » que ne l’est Ruby ?

[magnus2005]

il FAUT enseigner aux élèves comment fonctionne une machine, ce que sont les pointeurs (bé oui, on manipule que ça en java/c#)

Il faut avant leur enseigner comment analyser une demande client et comment y répondre.

C'est assez désolant de voir la quantité de développeurs (en devenir ou non) qui n'ont pas la moindre idée de comment est géré leur objet par la vm. Qui n'ont pas non plus la moindre idée de comment fonctionne leur PC,

A titre personnel je suis à 100% d'accord.
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.
Critère qui sont à mon avis :

• Livré du code maintenable
• Livré dans les temps

Pour être clair, j'ai fait du COBOL et du C, je n'ai aucun grief contre les pratiquants de ces langages.
Quelque soit la méthode à enseigner il faut avant avoir les bases de l'analyses, de factorisation et de rationalisation ça demeure très largement au dessus de paradigme de présentation de l'information.

Merci Tryph et aux autres aussi je me sens moins seul

Un point sur mon expérience perso :
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. Cela reste mon avis et je le partage. C'est pour ça que j'ai fait référence au difficultés de différent profil de s'adapter à la POO c'est nous sommes encore dedans pour une minorité des équipes. Équipes très très hétéroclites.

[Invité]

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.

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

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