Discussion :

[Artagnan-Bolt]

Bonjour tout le monde,

Je fais appel à vous parce que je suis fatigué de chercher sur Internet et d'avoir des réponses assez ...Je recherche des réponses les plus claires que possibles ou bien des titres de bouquins qui valent la peine de dépenser pour !

Premièrement, comment sommes-nous passé de la programmation impérative/ procédurale à la populaire orientée objet (s.v.p, je sais que plusieurs d'entre vous dirons que c'est pour nous facilité la vie, rendre notre travail plus efficace et organisée...). Voyez de ma perspective: qu'est-ce qui a poussé à la création de l'orienté objet ? Admettez-le, cela semble absurde de dire qu'une personne s'est réveillé un bon matin en se disant :« ça serait bien d'utiliser la notion d'objet dans la programmation ! ». Quelles sont les causes ?

Deuxièmement, c'est plus au niveau des langages de programmation. Si un programme est, en générale, une suite d'instruction, alors pourquoi avoir créé le concept de variable, de constante, de booléen, de type, de tableau, de boucles( en passant pourquoi 3 types de boucle, une n'était pas suffisant ! )...

Des livres sur la programmation informatique, j'en ai feuilleté et lu beaucoup comme la plupart d'entre vous...En conclusion, ils son vraiment loin d'être pédagogiques ! On dirait que les livres ne servent que de référence, mais pas pour nous apprendre la programmation tellement c'est lourd de théorie....et le pire SANS AUCUNE EXPLICATION sur le pourquoi on fait comme ceci et non comme cela !

J'espère que vous saisissez une image de ce que je ressens.

Merci d'avance pour votre future apport !

Arta Bolt

[sevyc64]

Bonjour tout le monde,

Premièrement, comment sommes-nous passé de la programmation impérative/ procédurale à la populaire orientée objet (s.v.p, je sais que plusieurs d'entre vous dirons que c'est pour nous facilité la vie, rendre notre travail plus efficace et organisée...). Voyez de ma perspective: qu'est-ce qui a poussé à la création de l'orienté objet ? Admettez-le, cela semble absurde de dire qu'une personne s'est réveillé un bon matin en se disant :« ça serait bien d'utiliser la notion d'objet dans la programmation ! ». Quelles sont les causes ?

parce que c'est une évolution naturelle vers le rapprochement avec le raisonnement de notre cerveaux permis par l'évolution des technologies.
Au départ, on avait la programmation séquentielle, parce qu'on ne savait faire que ça, mais ensuite, on a eu d'organiser le code en tâches, on a donc eu la programmation procédurale.
Parce que l'on a su aussi gérer par la suite, des faits qui arrivent de façon aléatoire, non plus en synchrone en allant vérifier fréquemment s'ils étaient arrivés, mais de manière asynchrone, en étant averti qu'ils venaient d'arrivé, on est passer à la programmation évènementielle.

Parce que dans la vie de tous les jours, nous même, nous ne traitons pas chaque chose dans leurs détails les plus fins mais comme étant des objets plus globaux, la programmation objet est une évolution naturelle de la Programmation.

Deuxièmement, c'est plus au niveau des langages de programmation. Si un programme est, en générale, une suite d'instruction, alors pourquoi avoir créé le concept de variable, de constante, de booléen, de type, de tableau, de boucles( en passant pourquoi 3 types de boucle, une n'était pas suffisant ! )...

Parce que le raisonnement ne se contente pas d'instructions. Il doit pouvoir à moment donné mémorisé des données, des résultats pour pouvoir s'en resservir après (variables), parce qu'il utilise aussi une donnée unique à plusieurs moments (constante) ....
Concernant, les boucles, si tu les étudie individuellement, tu te rendra compte que chacune ne peut couvrir tous les cas possibles et imaginable.

Mais tout ça ne relève pas de la programmation. Je dirais même que celà n'a rien à voir avec la programmation. Ça relève d'une matière qui devrait être parfaitement maitriser avant même de commencer à songer à attaquer la programmation quel qu’elle soit.
C'est une matière qui fait partie de la famille des mathématiques et qui s'appelle l’Algorithmie.
Malheureusement, bien des développeurs débutants (et moins débutants) ou zappé cette étape, et cela se voir généralement très vite dans le code

Des livres sur la programmation informatique, j'en ai feuilleté et lu beaucoup comme la plupart d'entre vous...En conclusion, ils son vraiment loin d'être pédagogiques ! On dirait que les livres ne servent que de référence, mais pas pour nous apprendre la programmation tellement c'est lourd de théorie....et le pire SANS AUCUNE EXPLICATION sur le pourquoi on fait comme ceci et non comme cela !

Si tu t’intéresse à des livre traitant tel ou tel langages, oui. Ces livres là ne sont pas là pour t'apprendre la programmation mais pour t'apprendre le langage (voire, bien plus souvent, l'évolution du dit langage depuis la version précédente).

Tu semble confondre Programmation et Langage de programmation. Si la programmation est l'art de construire une caisse en bois, le langage ne sera que le marteau/masse/cailloux/tasse de la grand-mère qui te servira à planter les clous pour construire ta caisse.

Il te faut donc trouver des bouquins, qui ne traite pas d'un langage en particulier, mais de la programmation en général. C'est plus rare mais ça existe.

Mais au delà de la programmation, si j'ai bien compris ta demande, c'est plus sur l'Algorithmie que porte ton attention. L'Algorithmie n'est pas spécifique à la programmation. Elle se pratique tous les jours par tout le monde sans même s'en rendre compte.

• Si le feux passe au rouge, j’accélère, sinon je fait gaffe au piéton qui traverse*
• Tant que ma cote de boeuf n'est pas cuite, je la laisse sur les braises
• Pour tous les articles que j'ai dans chariot, je les montrent à la caissière
• ...

Spécifique aux filles, le matin :

• Tant que j'ai une robe dans l'armoire, je l'essaye avant de choisir celle que je mettrais
• Si la robe que j'essaye est la dernière de l'armoire, j'irais au boulot en jean

* Je sais pas pourquoi lorsque j'essaye de compiler celui-là, j'obtiens une exception "Erreur irrécupérable : Votre permis a été annulé"

[fatbob]

Je dois admettre que je ne me suis jamais posé la question mais, d'un autre côté, l'évolution semble assez naturelle. Tous les exemples que tu cites répondent à des besoins évidents.
Si tu essaies de faire un programme impératif sans utiliser de variable, tu va vite te rendre compte que ça complique sérieusement l'affaire. Donc, quelqu'un qui se lance dans le développement d'un langage (et qui y réfléchit, il ne se lève pas un matin en se disant qu'il va créer son langage comme ci, comme ça en 1/2 h) va quasi nécessairement mettre en place ce genre de mécanisme.
De même, pour stocker les données dans ces variables, il a fallu créer des structures appropriés (chaînes, entiers, listes, tableaux...). Lorsque ces types n'existent pas nativement (ce qui peut être le cas pour des tableaux "clé"-"valeur", par exemple en VBA), le programmeur est souvent amené à développer lui-même un système pour remplacer ce manque, preuve que c'est utile.
Si l'on se place au niveau de la programmation impérative (je ne connais pas assez les autres types de programmation pour faire le même raisonnement).
Ce qui suit est juste un ramassis de suppositions mais la réalité ne doit pas ne être loin.

Au départ, les capacités des machines étaient relativement faibles et leur architecture poussait vers la création de suites d'instructions séquentielles.
On se retrouvait avec un script.

Evidemment, au fur et à mesure du temps, les scripts sont devenus de plus en plus complexes. On s'est rendu compte qu'il devenait nécessaire de regrouper certaines parties de code pour pouvoir les appeler plus facilement qu'en utilisant les fameux "GOTO" et pour éviter des redondances de code toujours préjudiciables à la maintenance.

On a donc créé les fonctions.

Et le temps est passés. Encore une fois, les limites du modèle sont apparues : des fonctions, c'est très bien mais lorsque les applications deviennent très complexes (genre un jeu vidéo), où stocke-t-on toutes les variables d'états de tous les personnages ? comment sait-on quelle fonction appliquer à quelle variable en fonction des caractéristiques du personnage choisi ?
Il devient alors évident qu'il serait utile de regrouper les états et les fonctions relatifs à un même concept. Et pan, c'est la programmation objet.
Dont les fondamentaux ne sont certainement pas nés un matin en se levant mais après réflexion autour de la question "Comment regrouper les états et les fonctions ?" ainsi que "Comment régler un certain nombre de problèmes qu'on peut s'attendre à trouver ?"

Si tu apprends la programmation à partir d'un langage comme python qui te permets de passer par chacune de ces étapes (sauf le goto) tu pourras te rendre compte par toi même du côté naturel de cette évolution.

[el_slapper]

Sachant aussi que chaque nouvelle étape est un outil en plus, pas forcément un outil qui remplace. Il est possible de faire du "tout objet", mais il arrive, suivant les cas, que ça ne soit pas une bonne idée(les zélotes de la programmation fonctionelle expliqueront ça mieux que moi).

Sinon, je suis d'accord avec fatbob. Le besoin a créé la conception. A chaque fois que les outils ont montré leurs limites, les gens ont tatonné, jusqu'à trouver des astuces qui leurs permettent de contourner lesdites limites. Astuces qui finissent par devenir standard.

[Artagnan-Bolt]

Mais tout ça ne relève pas de la programmation. Je dirais même que celà n'a rien à voir avec la programmation. Ça relève d'une matière qui devrait être parfaitement maitriser avant même de commencer à songer à attaquer la programmation quel qu’elle soit.
C'est une matière qui fait partie de la famille des mathématiques et qui s'appelle l’Algorithmie.
Malheureusement, bien des développeurs débutants (et moins débutants) ou zappé cette étape, et cela se voir généralement très vite dans le code

Tu semble confondre Programmation et Langage de programmation. Si la programmation est l'art de construire une caisse en bois, le langage ne sera que le marteau/masse/cailloux/tasse de la grand-mère qui te servira à planter les clous pour construire ta caisse.

Il te faut donc trouver des bouquins, qui ne traite pas d'un langage en particulier, mais de la programmation en général. C'est plus rare mais ça existe.

Mais au delà de la programmation, si j'ai bien compris ta demande, c'est plus sur l'Algorithmie que porte ton attention. L'Algorithmie n'est pas spécifique à la programmation. Elle se pratique tous les jours par tout le monde sans même s'en rendre compte.

• Si le feux passe au rouge, j’accélère, sinon je fait gaffe au piéton qui traverse*
• Tant que ma cote de boeuf n'est pas cuite, je la laisse sur les braises
• Pour tous les articles que j'ai dans chariot, je les montrent à la caissière
• ...

Spécifique aux filles, le matin :

• Tant que j'ai une robe dans l'armoire, je l'essaye avant de choisir celle que je mettrais
• Si la robe que j'essaye est la dernière de l'armoire, j'irais au boulot en jean

* Je sais pas pourquoi lorsque j'essaye de compiler celui-là, j'obtiens une exception "Erreur irrécupérable : Votre permis a été annulé"

Merci à Sevyc64 d'avoir soulevé le mot « algorithmie ». Dans mes cours de « programmation », les profs en parlent vraiment très peu et n'osent pas rentrer en profondeur pour ne pas mélanger les plus sensibles. Je suis entièrement d'accord que cette matière devrait être plus développée puisqu'elle ne dépend pas d'un langage spécifique. Des titres de bouquins ? Dans l'ère de l'information que nous vivons, il est difficile de trouver les « meilleurs » livres abordant ce sujet...sauf si vous l'avez lu. Donc, j'aimerais avoir vos suggestions ? Quelles sont les livres qui expliquent assez bien l'algorithmie à votre avis ?

Je vous remercie d'avance de vos partages en espérant que cela pourrait aider d'autres personnes.

Arta Bolt

[fatbob]

Il y a déjà ça :
http://algo.developpez.com/cours/

[sevyc64]

Merci à Sevyc64 d'avoir soulevé le mot « algorithmie ». Dans mes cours de « programmation », les profs en parlent vraiment très peu et n'osent pas rentrer en profondeur pour ne pas mélanger les plus sensibles.

Désolé d'être aussi franc et cassant, mais tes profs sont de mauvais profs !

La programmation ne peut se passer d'une base solide en algorithmie, la programmation n'existe pas sans l'algorithmie.
Il n'y a qu'à sans rendre compte à certaines questions que l'on reçoit sur le forum et le chat.

L'enseignement de la programmation ne devrait pas pouvoir commencer sans avoir au préalable acquis un minimum de bases en algorithmie, 10-15h est un minimum.
La plupart du temps, l'algorithmie représente la première heure de cours. Ensuite c'est plus ou moins (bien) enseigner au travers de la programmation mais sans la nommer, sans forcément être compris.

[wiztricks]

Salut,

Premièrement, comment sommes-nous passé de la programmation impérative/ procédurale à la populaire orientée objet (s.v.p, je sais que plusieurs d'entre vous dirons que c'est pour nous facilité la vie, rendre notre travail plus efficace et organisée...). Voyez de ma perspective: qu'est-ce qui a poussé à la création de l'orienté objet ?

Imaginez que vous deviez écrire un programme assez conséquent en BASH.
Pour le construire de façon sure, il faudra le découper en fonctions et modules.
L'espace des noms de variables (et des fonctions) étant "global", il faut faire attention aux collisions des noms. Lorsqu'un paquet de fonctions gère une ressource de type particulier (ex: file) vous allez avoir par exemple les fonctions file_create, file_open, file_read, file_write, file_close,...
file_create et file_open retourneront un machin opaque qui devra être passe en premier paramètre des file_read, file_write, file_close,...
Dit autrement: file_read file buffer len
Et nous avons crée un prototype d'objet sans langage POO.

Vous réalisez aussi qu'avoir a "structurer" le code d'une certaine façon pour arriver a construire de "gros code" devient contre-productif si des langages de programmation (dit POO) vous proposent déjà des solutions: plus besoin d'inventer un truc adhoc, le documenter, fliquer les développeurs pour qu'ils respectent ces règles,...

C++ a été pense en 78 et le premier compilo réalisé en 82/83.
Les difficultés de l’époque étaient que fabriquer un compilo et un éditeur de lien "supportant" ce genre de truc dépassaient capacités les CPU/Memoire/Stockage de l’époque et étaient "limite" cote savoir-faire.
Note: le manque d'ordinateurs réduit aussi l’éclosion des talents.
Ce n'est qu'a la fin des années 80 que la loi de Moore a réglé le problème et qu'il devenait intéressant de remplacer "Cobol".

Vouloir comparer les objets de la POO avec les objets du monde réel est devenu "mode", pédagogique,... Mais n'a fait qu'entretenir la confusion entre Conception Orientée Objet et la POO.

La Conception, c'est la capture des besoins clients et le design high level. Il y a bien sur des "objets": client, factures,... Mais ces objets la auront de multiples représentations cote application (une ligne dans une table, la chose qui est affichée,...) qui seront cohérentes ou pas sans que la POO puisse y faire grand chose.

- W

[MABROUKI]

bonjour Artagnan-Bolt

Sans algorithmie ,il n' y aurait pas probablement l'invention du calculateur ni de programmation...tout court..
Le lien entre calculateur et algorithmie vient du fait que les plus anciens algo depuis euclide etaient des algo de calcul numerique (racine crree,division etc...)
Au passage je n'ai jamais aime le mot ordinateur des academiciens qui ne veut rien dire,car B.Pascal avait deja donne le nom de table à calculer à sa machine...
La programmation n'est que la mise en oeuvre pratique d'un algorithme dans un langage donne sur un type de calculateur donne ...
Cette mise en oeuvre s'appelle couramment implementation d'un algo...
Ce qu'il faut signaler toutefois c'est qu'il y a abondance de livres sur l'algorithmie theorique en propre ,et sur les langages en propre.
Mais les livres utiles à l'homme de l'art que tu es et que je suis ,c.à.d traitant d'algorithmie accompagne d'explication sur sa mise en oeuvre (implementation) dans un langage donne(peu importe le language) sont beaucoup plus rares....
Ceci fait que, conjugue à des cursis officiels etriques,beaucoup de programmeurs decouvrent l'algorithmie à rebours (dans le retoviseur) qui finit par les rattraper...

J'ai lu beaucoup de livres en francais ,mais le meilleur ouvrage en introduction à l'algorithmie(elle est vaste) ,que j'ai lu c'etait Graphes et Algorithme de Gondran et Minoux ,en 1980 ( debut des pc et de mon premier IBM 8086)..Edition Eyrolles...
Ce livre a l'avantage d'introduire l'algorithmie en restreignant l'interet au domaine des graphes ...Les algo graphes sont indispensables en programmation et on les retrouve partout....

En langue anglaise ,un bon livre simple avec algo ,diagramme et exemples d'implementation en c++ et java ,facile d'abord :
Algorithms in a Nutshell by George T. Heineman, Gary Pollice, and Stanley Selkow -editeur :O’Reilly Media

Apres un livre general , le guide algo du programmeur professionnel senior ,simple egalement c'est :
-The Algorithm Design Manual de Steven S. Skiena-editeur Springer....
Quand on a une difficulte d'approche pour choisir un algo,consulter skienna...
extrait de la preface par Skienna et qui rejoint les propos tenus par sevy64:

Most professional programmers that I’ve encountered are not well prepared to
tackle algorithm design problems. This is a pity, because the techniques of algorithm design form one of the core practical technologies of computer science

C'est en effet le sentiment qu'on eprouve car le pauvre programmeur n' as pas ete prepare serieusement à son metier par qui de droit et c'est peu dire que la faute incombe à l'enseignant...

bon code....

[souviron34]

Je me permet d'ajouter mon grain de sel


"de mon temps", les cours d'infos étaient équivalents (entendre "étaient des") cours d'électronique....

On commence par apprendre les portes, les diodes, les transistors, les capacités.. De là on apprend les circuits élémentaires (NOR, AND, ADD, MUL, LOG, EXP).

De là, on apprenait à concevoir des fonctions plus compliquées..

Pour donc commencer à appréhender l'historique de l'évolution des concepts sous-jacents aux langages, il faut commencer à s'intéresser à ce sur quoi se basent des ordis, et ce à quoi ça s'applique...


Donc, d'une part les "ordiinateurs" sont une construction électronique, faite de circuits complexes découpés en circuits élémentaires, eux-même caractérisés par des éléments électroniques de propriétés distinctes :: résitance, transistor, diode, porte.

D'autre part, l'application de ces circuits a été principalement pour faire des maths et de la physique...

Donc, les concepts de variables, boucles, log, tableaux, etc, dérivent directement des fondements applicatifs, c'est à dire des maths pour lesquels les ordis étaient fabriqués. : une moyenne statistique est bien la racine carrée de la somme des carrés des écarts divisée par le nombre.... Il fallait donc quelque chose pour faire l'équivalent de Somme (i=0,i=N)... Aussi quelque chose pour faire une multiplication, pour faire une division, et pour faire une racine carrée..


Comme les mathématiques sont quelque chose de logique et de linéaire, une programmation électronique "linéaire" s'en est suivi... Et donc un langage linéaire...

Cependant, comme expliqué ci-dessus, la plupart des fonctions mathématiques un peu complexes font appel à des fonctions moins complexes (dans le cas ci-dessus "racine-carrée") . La notion de "sous-fonction" ou de fonction appelant une fonction apparait donc instantanément...


On a donc eu des langages comme Fortran... puis est venu C.


Ensuite, la plupart des "programmes" scientifiques devaient utiliser / créer des données de manière intensive... Mais la facilité du traitement "informatique" a séduit les banques, qui avaient des besoins spécifiques par rapport aux application scientifiques "traditionnelles" (militaires, aéronautiques, météo, et recherche). On a donc créé le concept de BDD, et des langages comme Cobol ont enfourché les concepts de Fortran en y ajoutant les BDD plus une certaine spécialisation vers les calculs financiers.

Bien entendu , des théoriciens dans ce nouveau domaine de "l"informatique" cherchent..


Tous les programmes scientifiques sont en général "linéaires", et suivent des algos de maths ou de physique... Les données en mathématique ou physique sont des "cas particuliers" d'un concept général qui est exprimé par une équation, un phénomène... Jusqu'au milieu des années 90 (et encore maintenant dans de nombreux domaines) les scientifiques programment toujours en Fortran (FORmula TRANslator), ou en C.... La notion "d'objet" n'a pas vraiment de sens en mathématique ou en physique (théorique)...


Maintenant, les recherches en informatique, additionées du fait que l'on s'est mis à enseigner de "linformatique" à des non-scientifiques depuis la fin des années 70, à rendu populaire les concepts "objets". Il n'y a pas un concept meilleur que l'autre. Ce sont 2 concepts différents avec 2 approches différentes.

De mon point de vue de physicien, il est parfaitement absurde de fabriquer un programme basé sur le concept "une lettre se poste" (c'est à dire un objet "lettre" avec une méthode "se poster") . Pour moi il y a bien un objet "lettre", mais comme tout objet il est inerte. C'est l'utlisateur (un humain) qui lui fait subir une action...

Pour les gens ayant appris dans leurs cours l'objet comme fond, ils ne comprendront pas mon raisonnement. Pour les physiciens et mathématiciens, si l'on regarde le fonctionnement de la pensée sur ce qu'on cherche à programmer, le "naturel" est le procédural.

Il y avait un excellent post dans un autre thread à ce sujet. J'essaierais de le retrouver..

En gros: le "procédural" (et un mathématicien ou physicien) analyse son problème - et donc veut le programmer - en termes de fonctionalités.

Si je fabrique un programme de traitement d'image, mon analyse sera

• lire une image
• la stocker
• lui appiiquer traitement A
• lui appliquer traitement B
• itérer

C'est bien linéaire, je manipule un objet "image", et je lui applique des fonctionalités "traitement A" ou "traitement B" suivant ce que j'ai rentré.

Maintenant, un programmeur formé à l'objet créera un programme qui sera basé sur un objet image ayant dans ses méthodes de classe "traitement A" ou "traitement B" et fera dépendre l'application du traitement d'une IHM.


On voit bien qu'il n'y a pas de différence de fond, simplement de manière de concevoir le programme (ou l'objet).

[souviron34]

J'ai retrouvé le post en question...

• Dans le thread Les avantages du procédurals par rapport à l'orientée objet? le post #61 (posté par un prof d'info de Sherbrooke) résume bien la situation...
  
  
• Un autre débat (beaucoup plus court, et pointant d'ailleurs sur celui cité plus haut) est comparaison procédural - objet svp ?
  
  
• Sinon, deux autres threads intéressants à lire pour répondre à tes questions peuvent être [Débat] modèles full OO et sources de données, est-ce un mythe? ou [Débat] Langage Fonctionnel vs Langage impératif

[fatbob]

Je me permet d'ajouter mon grain de sel
De mon point de vue de physicien, il est parfaitement absurde de fabriquer un programme basé sur le concept "une lettre se poste" (c'est à dire un objet "lettre" avec une méthode "se poster") . Pour moi il y a bien un objet "lettre", mais comme tout objet il est inerte. C'est l'utlisateur (un humain) qui lui fait subir une action...

Je pense qu'il y a dans cette phrase une confusion.
Ce n'est pas parce que la méthode "poste" fait partie de l'objet lettre que l'on considère que la lettre "se poste" elle même. Par contre, elle s'applique à la lettre.
Je ne peux pas "poster" ma maison.

De même, un véhicule dispose d'une "méthode" "accélérer".
C'est logique car cette méthode, cette façon d'accélérer, est propre à ce véhicule. En tant qu'opérateur, je ne peux pas appliquer d'autre façon d'accélérer à ce véhicule. Sauf à le pousser, éventuellement, mais c'est un peu tiré par les cheveux.

Prenons le cas d'un jeu vidéo avec des tas de personnages qui ont tous des attributs et des méthodes différentes en fonction de certaines caractéristiques (disons pour faire simple "barbare", "mage"...").
Si l'on considère que les méthodes ne peuvent pas être regroupées avec les attributs dans un "objet", alors, on va avoir d'un côté des structures de données complexes qui vont décrire l'état de chacun des personnages, et, d'un autre, un énorme tas de fonctions qu'il faudra choisir et appliquer à bon escient à tel ou tel personnage ou élément du décor.

Pour moi, l'objet est un niveau d'abstraction supplémentaire par rapport au procédural. Une évolution.
La meilleure preuve, c'est qu'il est tout à fait possible de faire un programme procédural dans un langage objet. J'irai même jusqu'à dire que tout programme objet contient des parties procédurales puisque les méthodes des objets sont des fonctions.
Par contre, il n'est pas possible (ou au moins très compliqué) de faire de l'objet dans un langage qui n'est pas prévu pour.

[souviron34]

Pour moi, l'objet est un niveau d'abstraction supplémentaire par rapport au procédural. Une évolution.

Non, comme le dit le post cité dans mon précédent post...

C'est une manière différente, c'est tout...

Piour moi, comme pour la plupart des physiciens (et des mathématiciens et logiciens), un "programme" est une suite de fonctionalités qui s'appliquent sur des "objets".

Mon point de vue est une suite de fonctionalités... L'architecture de mon programme se construit autour des fonctionalités, les "objets" étant simplement ce sur quoi s'appliquent ces fonctionalités.

Du point de vue OO, c'est une suite d'objets.. L'architecture du programme est donc construite autour des objets, les "fonctionalitésé étant spécifiques des objets (ou de leurs classes).

C'est en ça que les conceptions sont différentes : cela influe sur l'architecture.


Si je prends tes exemples, "mage", "barbare", sont pour moi des "humains".

Ces humains ont des propriétés, et tous disposent de tous les outils fabriqués par l"humanité. Certains on eu droit à un apprentissage spécifique.

Cela ne les empêche pas de se comporter strictement de la même manière lorsqu'il s'agit de plier les genoux, de prendre un bâton, de tuer quelqu'un..

Pour moi, j'ai donc une panoplie d'actions, une panoplie d'outils, une panoplie de comportements, et un "objet" de type "humain", qui se sert là-dedans (comme un programme se sert dans une bibliothèque), mais qui peut en avoir plusieurs en parallèles : un "mage" peut tout à fait devenir barbare : l'Histoire est là pour nous le montrer tous les jours... Un médecin ou un (sur)diplômé peut devenir barbare, et un barbare peut être un dictateur éclairé...

Comme le dit Garulfo dans le post cité,,

Dans le premier cas tu vois le monde comme des objets qui communiquent entre eux pour résoudre une tâche. Chaque objet connait ce qu'il a à faire et comment il a à le faire. Il envoie des messages, à lui ou aux autres pour demander quelquechose. La paradigme procédural voit le monde comme une ensemble de fonctions qui collaborent. C'est une vision plus « mathématique » bien qu'il faille faire attention à ne pas faire un parallèle sans nuance. Résoudre un problème c'est appeler la bonne fonction qui elle-même appellera les autres qui lui sont nécessaires.

L'OO, c'est mettre les données en avant et décomposer le problème selon les relations (la complexité) entre ces données. Le procédural, c'est mettre les fonctionnalités en avant et décomposer le problème selon la complexité fonctionnelle.

Cela résume tout à fait...


Ce n'est pas un niveau d'abstraction pus élevé...


Quant à :

La meilleure preuve, c'est qu'il est tout à fait possible de faire un programme procédural dans un langage objet. J'irai même jusqu'à dire que tout programme objet contient des parties procédurales puisque les méthodes des objets sont des fonctions.
Par contre, il n'est pas possible (ou au moins très compliqué) de faire de l'objet dans un langage qui n'est pas prévu pour.

Alors là

La quasi-totalité des "langages" objets est fabriquée à partir de langages procéduraux (C par exemple)...

Tu trouveras dans les discussions citées les exemples qui montrent comment on peut très rapidement écrire du OO en C...


En gros, la différence est :

• Dans un cas on a : rectangle.trace(), carré.trace(), cercle.trace(), donc objet.trace()
• Dans l'autre on a : trace(rectangle), trace(carré), trace(circle), donc trace (objet)

On voit bien que la différence n'est en rien un "niveau d'abstraction", simplement une manière de penser...

[sevyc64]

Pour moi, l'objet est un niveau d'abstraction supplémentaire par rapport au procédural. Une évolution.

Non, ce n'est pas un niveau d'abstraction supplémentaire, les objets et la programmation objet ne se situe pas au dessus de la programmation procédurale.

C'est un niveau d'organisation logique différent. Là ou d'un coté (procédural) on a une série de variables et une série de procédures sans lien direct, on a, de l'autre, regrouper les variables et les procédures qui leur sont propre dans des entité que l'on nomme objet.

La meilleure preuve, c'est qu'il est tout à fait possible de faire un programme procédural dans un langage objet. J'irai même jusqu'à dire que tout programme objet contient des parties procédurales puisque les méthodes des objets sont des fonctions.

Mais tout à fait.
Et je vais te donner un scoop, la POO fait aussi appel à la programmation événementielle ainsi qu'à la programmation séquentielle, tout comme la programmation événementielle est à la base une programmation procédurale, cette dernière n'étant finalement, à l'intérieur de chaque procédure que de la programmation séquentielle.

Il ne s'agit pas de mettre en concurrence telle ou telle méthode de programmation, elles sont toutes complémentaires et indissociables.
Et ce n'est pas parce que la programmation séquentielle a été inventé au tout début et qu’aujourd’hui on en est à la POO que la séquentielle est morte et enterrée. Bien au contraire, elle est toujours utile et utilisée là ou elle remplie pleinement son rôle et où les autres formes de programmations n'apporterais rien de plus (chaines de fabrication robotisée, entre-autre, par exemple)

[el_slapper]

(.../...)Il ne s'agit pas de mettre en concurrence telle ou telle méthode de programmation, elles sont toutes complémentaires et indissociables.
Et ce n'est pas parce que la programmation séquentielle a été inventé au tout début et qu’aujourd’hui on en est à la POO que la séquentielle est morte et enterrée. Bien au contraire, elle est toujours utile et utilisée là ou elle remplie pleinement son rôle et où les autres formes de programmations n'apporterais rien de plus (chaines de fabrication robotisée, entre-autre, par exemple)

+1

En fait, on reste en séquentiel/procédural partout ou la POO pose plus de problèmes qu'elle n'en résout. J'ai passé beaucoup de missions à faire des batches énormes(en complexité, pas en complication) pour des grands comptes. Il y a toujours de nouvelles manières de torturer les données inventées par les utilisateurs et les MOA.

Si on faisait de l'objet, ça aménerait des classes d'une complexité invraisemblable. Le nombre de méthodes serait hallucinant, et chaque programme devant se servir d'un petit bout de la donnée devrait se trimballer l'ensemble.

A contrario, la méthode séquentielle, c'est de prendre une définition de donnée "nue", sans méthode, et, dans le programme qui va bien, de faire ce qu'il y a à faire. Et il y a finalement fort peu de redites.

Donc, quand on a un plantage sur le traitement du client par la chaine marketing, on va regarder le traitement marketing. Le nombre de traitements différents du client est absolument colossal, et la classe serait ingérable. Le programme marketing, lui, est plus simple, et on voit directement ou est l'erreur.

Ca ne m'empeche pas de faire de l'objet quand le besoin s'en fait sentir. Quand on a des structures rigides, aux interactions prévisibles et standardisables, l'objet est excellent. et il permet une flexibilité totale..... à l'interieur de cette rigidité. L'interface contenant la définition des données, mais aussi des méthodes, est la définition de cette rigidité. Tant qu'on se conforme à l'interface, l'objet est super souple et pratique. Dès qu'on doit régulièrement trafiquer l'interface, ça tourne vinaigre.

[fatbob]

Du point de vue OO, c'est une suite d'objets.. L'architecture du programme est donc construite autour des objets, les "fonctionalitésé étant spécifiques des objets (ou de leurs classes).

Ce qui me gêne dans ton raisonnement, c'est que tu dis "Du point de vue OO"...
Pour ma part, je pense être du côté OO... comme tu as pu le déceler à quelques indices subtils :-)
Or je ne vois pas un programme comme une suite d'objets.
On peut admettre quelque chose comme un ensemble d'objets. La nuance est importante car elle ne donne pas de notion d'ordre.

C'est en ça que les conceptions sont différentes : cela influe sur l'architecture.

Si je prends tes exemples, "mage", "barbare", sont pour moi des "humains".

Ces humains ont des propriétés, et tous disposent de tous les outils fabriqués par l"humanité. Certains on eu droit à un apprentissage spécifique.

Cela ne les empêche pas de se comporter strictement de la même manière lorsqu'il s'agit de plier les genoux, de prendre un bâton, de tuer quelqu'un..

Ce cas particulier est tout à fait pris en compte par la notion d'héritage. Il n'empêche que "plier le genou" est une action qui peut être exécutée par un humain mais pas par une voiture ou une table.

Cela résume tout à fait...

Je ne suis pas tellement d'accord avec le point de vue de Garulfo.
Pour moi, l'Objet est d'abord et avant tout un moyen de regrouper données et méthodes de façon à améliorer la réutilisabilité...
Après, les questions d'échanges de messages ou de fonctions qui collaborent, tout ça, je ne suis pas trop. Les méthodes des objets s'appellent également entre elles et collaborent.
La proposition que le procédural est plus mathématique me semble on ne peut plus douteux et sans aucun argumentaire (énoncé).

La quasi-totalité des "langages" objets est fabriquée à partir de langages procéduraux (C par exemple)...

Argument qui n'en est pas un.
La quasi-totalité des langages est fabriquée à partir de l'assembleur (C y compris).
Après, à partir du langage de base, on redéfinit une nouvelle grammaire, de nouvelles fonctionnalités qui vont permettre de mettre en oeuvre certains concepts plus facilement.

Un langage objet (prenons python, par exemple) peut faire du procédural sans difficulté. Il suffit de ne pas écrire "class" et, pour les objets natifs, de remplacer objet.méthode par méthode(objet). Ca marche.
Faire de l'objet avec du C... C'est autrement plus ardu. Je sais que c'est possible, j'en ai fait à l'école. Mais bon. Ca ne respecte pas bien tous les principes de la POO et on sent bien que ce n'est pas sa vocation.

Si je regarde les grammaires des langages procéduraux et des langages objets, je vois que la grammaire des langages objets est un sur-ensemble de celle des langages procéduraux, et que la partie supplémentaire est ce qui me semble bel et bien définir un niveau d'abstraction supplémentaire. ca n'est qu'un avis, c'est sûr mais quand je conçois un programme, j'ai l'impression de pouvoir manipuler des concepts plus abstraits dans le paradigme objet.

Dans un cas on a : rectangle.trace(), carré.trace(), cercle.trace(), donc objet.trace()
Dans l'autre on a : trace(rectangle), trace(carré), trace(circle), donc trace (objet)

Ca va un peu plus loin car dans le deuxième cas, je vais avoir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
def trace(forme):
    if forme == 'rectangle':
        trace_rectangle()
    elif forme == 'carré':
        trace_carré()
...

alors que dans le premier, le fait que toutes les méthodes s'appellent "trace" ne pose aucun problème. C'est même un cas classique.

[souviron34]

Je ne vais pas refaire toute les discussions. Lis les liens, il y a les exemples exacts...

[fatbob]

Ce n'est pas parce que la programmation séquentielle a été inventé au tout début et qu’aujourd’hui on en est à la POO que la séquentielle est morte et enterrée. Bien au contraire, elle est toujours utile et utilisée là ou elle remplie pleinement son rôle et où les autres formes de programmations n'apporterais rien de plus (chaines de fabrication robotisée, entre-autre, par exemple)

Je ne dis pas le contraire.
Je ne prétends en aucun cas que la programmation séquentielle est morte et enterrée et qu'elle est sans intérêt et n'a plus aucun rôle.
Par contre, je persiste sur la question des niveaux d'abstraction... Qui n'ont pas forcément lieu d'être utilisés en toute situation, par exemple pour des scripts systèmes.

[souviron34]

Par contre, je persiste sur la question des niveaux d'abstraction...

Et tu as tort

Concevoir un programme appliqiuant des fonctionalités quelcquonques à un "objet" décrit de manière générale est strictement au même niveau d'abstraction que concevoir un programme décrivant des classes d'objets particulières pouvant n'avoir que tel ou tel traitement..

Comme dit plus haut, ça dépend du point de vue, sans plus....


La notion de "widget" dans une IHM est née avec X11, codé en C, par des ingénieurs ayant une parfaite maîtrise du Fortran et du C.. Et contenant une part essentielle de programmation événementielle... Qui est aujourd'hui la base de ce qui fait C++, Java, Python, et autres... et cela fait 40 ans que cette notion perdure.... Pour un "faible niveau d'abstraction", bonjour

La bibliothèque X11 n'a subit que de très légers remaniements depuis 1984 - seulement sur l'inclusion de modèles de couleurs pour l'imrprimerie ou la photo professionnelle.... Mais est toujours à 99.9% identique à ce quel'elle était à l'époque des minis-ordinateurs, et pourtant elle est utilisée par Gnome, KDE, GTK, wxwidgets, Java, etc, pour afficher sous Linux (ou cygwin sous Windows) ..

Pour moi, l'Objet est d'abord et avant tout un moyen de regrouper données et méthodes de façon à améliorer la réutilisabilité...

Encore une fois, comme le dit el_slapper, ça dépend..

Les bibliothèques sont un excellent moyen d'améliorer la réutilisabilité, et l'appel à une de leurs fonctions est plutôt procédural, non ??

Quand tu vas appeler une méthode "sqrt", tu vas pas en faire une pour chaque objet ??

La réutilisabilité des programmes "procéduraux" est basée sur l'utilisation massive de bibliothèques - le modèle en couches... celle du modèle objet sur l'utilisation d'objets ou de classes...

Suivant les domaines, il n'est pas rare, comme noté par el_slapper, que ce soit plus réutilisable d'utiliser des bibliothèques que des classes...

La proposition que le procédural est plus mathématique me semble on ne peut plus douteux et sans aucun argumentaire (énoncé).

C'est pourtant le cas ... Une équation thermodynamique est valable que l'objet soit un courant marin, un flux de chaleur dans une chaudière, le flux de pétrole dans un moteur à combustion, ou le flux de neutrons dans une combustion nucléaire..

On écrit donc un programme calculant les équations, et on y injecte une "donnée", qui a tout un tas d'origines ou de particularités différentes, avec pour seul point réellement commun d'être un "fluide" au sens thermodynamique.. (qui n'est pas le sens commun) . De même pour de la météo, de l'aéronautique, etc etc...

Encore une fois, ce n'est pas pour rien que le FORTRAN est l'abréviation de FORmula TRANslator : "traducteur de formules"...


Mais d'une part on sort du sujet du PO, et d'autre part tous les arguments ont déjà été donnés dans les discussions en référence... et on ne va pas refaire une énième discusssion sur le sujet... tout a été dit dans ce qui était cité..

[fatbob]

J'ai quand même un dernier truc à préciser : je n'ai jamais dit que la programmation procédurale n'était pas bien et qu'on ne pouvait rien faire de bien avec.
Je n'ai pas dit non plus que le niveau d'abstraction des langages procéduraux était faible. Discréditer le contradicteur en exagérant son propos à outrance ne permet certes pas d'avoir un échange constructif.

C'est évident qu'on peut tout faire avec un langage procédural. On peut même tout faire avec de l'assembleur ou avec des langages fonctionnels (genre OCaml et consort) où là, pour le coup, je vois bien la réelle différence de paradigme.
De toute façon, un langage quelqu'il soit est transformé en une suite de 0 et de 1 à l'arrivée.

Autre point... La programmation événementielle n'est pas antinomique avec la programmation objet... On peut tout à fait avoir des objets qui surveillent d'autre objets "événements".

Enfin, tu parles d'équation thermodynamique en disant que ça marche mieux dans un programme procédural alors que tu dégages toi-même l'objet dont hérite les courants marins, les flux de neutrons et autres : le fluide.

En disant ça, je ne dis pas que le procédural ne marche pas ou qu'il n'est pas adapté. Je dis simplement qu'en passant à l'objet, apparaît un niveau d'abstraction supplémentaire (ici incarné par le fluide dont tous les autres vont hériter).
J'ai l'impression que cette histoire de niveau d'abstraction est vécu comme un méchant coup de sabre alors que pour moi, c'est juste une caractéristique. Sans a priori positif ou négatif...