Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
à tous de cet aparté à la fois distrayant et instructif, mais le but du sujet n'est pas de savoir si smalltalk est mieux que c++, ni de savoir si une usine à gaz basée sur des webservices et saturant le réseau de communication mode texte en xml peut être justifiée
(bien sûr, je caricature)
ce serait bien vu de revenir sur le débat initial...
je le pense ouiEnvoyé par Jean-Marc.Bourguet
C'est ce que je répète depuis le début : il me semble que le fait de donner l'épithète "objet" à une conception pour décrire un ensemble de choses/comportements sous-tendues par les concepts "objet" tels qu'utilisés dans les langages objets est un biais de réflexion.
En d'autres termes, on trouve la solution correspondant à ce qu'on voulait trouver (du style LaPalice ou tautologie).
Comme tu dis ici :
Comme les exemples que tu cites : le vocabulaire utilisé pour donner ces exemples contient en lui-même le recouvrement avec la "conception objet" des langages objets, et donc naturellement il apparaît que la "conception objet" est décrite par cela. Un peu l'histoire du chat qui se mord la queue...La conception orientee objet c'est des techniques de conception tendant a trouver les solutions a un probleme qui font usages de la programmation orientee objet.
Alors que pour moi l'orienté objet est plus une séparation conceptuelle pure d'entités ayant des propriétés et des actions communes et modélisables, sans plus. Donc sans formalisation par des termes autres que des termes du métier que ces objets recouvrent.
Un exemple : pour moi, le concept de "police de caractère" (ou "font" en anglais et "fonte" en français) est de la conception orientée objet. On a identifié que pour imprimer N'IMPORTE QUEL TEXTE (donc un concept (ou objet) TEXTE), on avait besoin d'un concept (ou objet)"FONTE" (qui au passage doit son écriture française autant qu'anglaise à la vraie imprimerie, les jeux de caractères étant des moules en fonte sur lesquels était placée l'encre). Cet objet FONTE était un regroupement d'objets individuels (les "caractères") possédant des propriétés communes (inclinaison, décorations, hauteur au-dessus et en-dessous de la ligne médiane).
Que l'on formalise ceci plus loin en parlant d'héritage et d'attributs et .. est à mon avis de la surenchère technique. Mais de mon point de vue le paragraphe précédent EST DE LA COO.
Et en reprenant ce que je disais sur les emplois et/ou annonces, je pense que ce biais de pensée est fortement implanté. Mais il n'empêche pas qu'il me semble un biais
On rentre ici dans une toute autre discussion...
Quelqu'un (A. Kay dans le cas present) introduit un nouveau style de programmation dans les annees 70. Il l'appelle programmation orientee objet. La chose a un interet. Au cours des annees, on en explore les variantes, les limites. Le terme prend un sens plus large que ce que a quoi l'auteur initial pensait vraissemblablement (cf la phrase attribuee a Kay: I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.) mais quand meme relativement precis.
C'est vrai pour oriente objet, comme pour d'autres termes -- programmation structuree, programmation generique, programmation logique,... pour ne citer que des choses similaires a programmation orientee objet.
Ce mecanisme est vrai dans tous les domaines.
Que ca te plaise ou non, si tu te mets a reinterpreter la signification de ces locutions dans un contexte technique a partir du sens initial des mots qui les compose, on ne te comprend pas.
Moi je pense que la POO s'appuye aussi sur le concept d'interface et d'implementation
on concoit d'abord une interface c'est la phase de modelisation
ensuite on creer l'implementation
de ce fait toutes implementation qui respecte l'interface peut être utilisé.
elle permet de séparer le logiciel en plusieurs modules indépendant
ceux qui utilise l'interface et ceux qui implemente une interface
ceci permet d'isolé les composant pour les tests unitaire
il se base aussi sur le concept diviser pour mieux reigné
ce concept est réellement indépendant du langage on peut l'utilisé en C en Java en C++ en python etc..
Cette organisation est la base même pour gérer de très très gros projet même avec un langage non typé
La POO permet de gérer des projets énorme avec des langages ayant des fonctionalite permettant de gérer cette notion d'interface et d'implementation
Vous êtes franchement contents de vous battre à qui mieux-mieux en termes de nombre de lignes de code ? En ce qui me concerne, lorsque je vois qu'une application fait 68 millions de lignes de code comme Vista, j'ai de très gros doutes quant à la qualité de l'ensemble.
Linux a été fait sans ce genre de méthodes... et vous savez quoi ? Ca marche, et pour ceux qui sont contents de se battre à coups de lignes de code, le noyau fait déjà 6 millions de lignes... hallucinant, non ?
GHS3D (environ 150 000 lignes), le mailleur 3D le plus rapide du monde, est fait en FORTRAN 77 par une seule personne qui ne connaît rien à l'objet et ce genre de trucs. Si je donne cet exemple, c'est que je connais bien les gens qui s'en occupent.
Des exemples dans ce genre on pourrait en trouver des milliers.
La conception objet apporte un plus indéniable, mais le tout objet est très préjudiciable pour la qualité d'une application, à mon sens, notamment parce qu'il est difficile de construire des structures de données complexes (arbres en tout genre, et autres). Le tout objet tombe dans le même excès que le tout fonctionnel : bien adapté à certains cas, très mal adapté à d'autres.
L'approche que prône OCaml et une bonne et saine programmation en C restent encore pour moi le nec-plus-ultra.
ton mailleur 3D il sert bien quelle que chose , il sert a un autre logiciel
et ben tu vois faire de l'objet c'est modeliser ton mailleur 3D avec une interface après celui qui aura besoin d'un mailleur 3D utilisera l'interface
ce qui lui permettre d'être indépendant de l'implementation et d'en utilisé un autre qui pourra être plus performant.
ce concept est utilisé pour les drivers par exemple opengl est une interface normé quand tu fait de la 3D tu t'occupe pas de savoir si ta carte est de tel marque et ainsi de suite heureusement que la poo est la car sinon
il faudrait programmer autant de version de logiciel qu'il y a de carte...
Ce concept est une des base d'informatique...
Ces comme une voiture elle une interface qui te permet de la conduire.
Tu n'a pas repasser un permis a chaque fois que tu change de voiture...
De plus je trouve ca instructif de discuté et de pas être d'accord car ca oblige
a argumenté par des faits... et donc on apprend..
Ah parce que dès qu'un programme dispose d'une interface c'est qu'il était conçu objet
Donc cela signifie par exemple que tous les appels systèmes de Linux sont OO. Bah oui, ils disposent tous d'une interface pour être utilisés par d'autres programmes...
En gros, ce que tu dis, c'est que sans POO il faut réinventer la roue à chaque fois... Pourtant on a pas attendu SIMULA 67 pour faire des librairies FORTRAN réutilisables...
Non c'est pas du tout ce que j'ai dis
si un programme n'utilise aucune interface et implementation il n'est pas objet
L'interface du mailleur en question c'est le type de fichier qu'il prend en entrée et le type de fichier qu'il rend en sortie (qui se trouve être le même en fait). C'est un programme à part entière. La modularité, c'est aussi avoir des utilitaires très spécifiques que l'on assemble pour donner une chose plus grande, plutôt qu'une usine à gaz qui fait quelque chose (de générique, bien-sûr, sinon c'est pas bien), mais on ne sait pas trop quoi. C'est la philosophie Unix originelle et je pense qu'elle est bonne.
Comme a peu pres n'importe quelle methodologie de conception datant d'apres les annees 60.
Pas particulierement. Cet aspect de la discussion n'a pour moi concerner qu'un aspect accessoire et derive: l'adequation des langages types dynamiquement aux gros projets. Et c'est difficile de comparer des projets sur ce point sans parler de nombre de lignes, de nombres de personnes ou d'age.
On peut aussi discuter de l'interet de faire des projets aussi gros. Mais c'est encore un autre sujet.
Ai-je jamais ecrit autre chose? Mais je ne suis pas d'accord avecLa conception objet apporte un plus indéniable, mais le tout objet est très préjudiciable pour la qualité d'une application... Le tout objet tombe dans le même excès que le tout fonctionnel : bien adapté à certains cas, très mal adapté à d'autres.
Je n'ai jamais eu aucun problemes avec ca.à mon sens, notamment parce qu'il est difficile de construire des structures de données complexes (arbres en tout genre, et autres).
globalement on peut faire des projets de tres tres grande taille en développant en couche
un logiciel repose sur un OS qui est composé de millions de ligne de code .
si l'OS est développé par la même société on peut parler d'un tres gros Projet
OS+logicel
Moi je pense que dans votre société vous ête mal organisé ou tous les objets qui compose votre projet sont fortement lié , ce qui est possible et dans ce cas peut-être qu'éffectivement un lanage typé est essentiel ...
bon je dirais par rapport aux 2 ou 3 pages qui précèdent :
- un BON projet ne dépend pas de la taille
- un GROS projet qui marche ne dépend pas du langage (ni de la METHODE) utilisée.
- comme on l'a dit plus haut, on peut faire un MAUVAIS projet en langage objet et un BON projet en Fortran
Exemples (publics et largment utilisés) :
- les kernels linux, unix, VMS, RT11 (que je connais) : sans langages objets, sans "conception objet" comme le dit JM.
- Les bibliothèques de maths du CERN (+20 millions de lignes de code, Fortran, conception fonctionnelle).
- Le code de HTTP ou de Mosaic (ancêtre de Netscape) : sans langages objets, sans "conception objet", en C.
Donc arrêtez de vous écharper là-dessus c'est totalement inutile.
D'autre part, je reviens à la question initiale qui je le rappelle était : est-il nécessaire ?
Et je re-dis : non ce n'est pas nécessaire...
Quant à la maintenabilité, je re-dis la même chose : si la conception est logique, c'est facilement maintenable. Si elle est illogique, c'est un enfer.
Mais en aucun cas les langages objets ne sont destinés à faciliter la maintenance.
Oui parce qu'il y a des fichiiers de config
Mais ça n'est pas ça qui fait que c'est de l'objet...
Et à plus forte raison avec le point de vue de JM..
Je crois que c'est l'inverse
Ce n'est pas parce qu'un terme est utilisé avec une certaine signification dans un certain milieu à un certain moment que c'est bien la signifcation de ce terme.
Exemple :
Un démarreur aujourdh'hui est un truc d'électronique avec tout un tas de circuits..
Mais vas-tu me dire qu'une 4L, une 2CV, une traction avant n'ont pas de démarreur ??
Pareil pour l'ensemble de la voiture. Ce n'est pas parce que dans l'acceptation des constructeurs d'aujourd'hui une voiture est quasiment de l'électronique pure qu'une Cadillac des années 50 ou une Renault 16 n'est pas une voiture ....
Ce n'est pas moi qui me met à "réinterpréter" la signifcation de mots. C'est un certain milieu d'aujourdhui qui interprète à sa façon la signification de mots et lui adjoint un sens connu uniquement de lui, et qui dit aux autres "non ce n'est pas le sens que vous connaissez" .
Moi je trouve qu'il y a bcp de gens ici qui devrait lire le livre
C++ Java, Smalltalk : les concepts objet à l'épreuve
Auteur(s) : PRADOS
Avant de poster des messages....
Je suis pas du tout d'accord avec toi l'objet est indispensable maintenant pour des raisons de productivité.
Oui on peut faire un Tres tres gros projet qui fonctionne quelque soit le langage
Mais a quelle prix.....
Indispensable... Comme tu y vas fort. Tout dépend du type de projet. Je ne vois pas en quoi un système d'exploitation par exemple devrait intégrer une approche OO. Comme il a été dit, selon les problèmes à résoudre, l'approche ne doit pas être la même. Beaucoup de problèmes mathématiques sont plus facilement solvables en utilisant une approche fonctionnelle. Rien n'empêche de définir une interface pour utiliser ces solutions. La conception ne sera pas OO pour autant
Pour les mêmes raisons, je n'aurais pas l'audace de dire que l'OO rend plus productif. Il faut analyser au cas par cas. Dans beaucoup de cas, une COO permet de simplifier l'élaboration d'un programme et rend ainsi plus productif, mais il ne faut pas généraliser.
Recentrons le débat.
Mon premier post pour moi, je me permet de citer la question posé en tout début de post.
Je te donne mon avis basé sur mon expérience et sur ce que je vis au quotidien (j'encadre un service de 35 ingénieurs en développement).
Je ne vais pas te parler de théorie mais d'industrie car ça je connais bien, c'est mon gagne pain.
Tu dois considérer que les langages sont au service de la conception et ne sont que des outils qui vont te permettre de bâtir l'application que tu dois livrer.
Il faut en effet, comme il est cité plus haut, distinguer la conception objet des langages de programmation orienté objet (je reprends volontairement tes termes). En effet les puristes vont commencer à te parler de langage "orienté objet", "à objet" ou "basé objet" or toi tu cites la "POO" donc la Programmation Orientée Objet.
Je rappelle la définition du mot Ingénierie :Il va de soi que de nos jours un ingénieur en génie logiciel se doit de connaitre les concepts objets et de maitriser un ou des langages orientés objet (ou "à objet").Ingénierie, subst. fém. ,,Ensemble des fonctions allant de la conception et des études à la responsabilité de la construction et au contrôle des équipements d'une installation technique ou industrielle.
La question n'est pas de savoir si c'est mieux ou moins bien que d'autres langages et d'autres approches, c'est juste qu'il faut savoir que c'est utilisé dans l'industrie et les méthodes de conception objet ainsi que les techniques (par technique j'entends langages) ont été adoptées pour tous types d'application.
Attention cela ne veut pas dire que dans la pratique la maitrise par les équipes de développement des concepts et des langages soit arrivée à maturité, je fait juste état d'un constat : l'objet est là et il faut faire avec.
Ensuite sans rentrer dans le débat des puristes et autres théoriciens (que je ne suis pas) j'ajouterai que non ce n'est pas la réponse à tout, c'est une réponse comme une autre qui a ces avantages et ces inconvénients.
C'est là qu'intervient le savoir faire de l'ingénieur : quelle méthodes et quelle techniques sont les plus adaptées pour répondre à mon besoin (cahier des charges) et selon les critères d'exigence (prix, délai, qualité).
Dans l'industrie les langages comme le C++ ont su démontrer leur capacité à permettre de réaliser des applications de toutes sorte malheureusement ils ont aussi permis de hisser les problématiques de pointeurs nuls en tant qu'art à part entière.
Donc pour répondre à ta question oui il est important de connaitre les formalismes objet et oui cela devient quasiment une nécessité.
Une dernière chose, ne pas confondre conception et programmation
Oui il ne faut pas confondre conception et programmation objet mais dans 99% des cas quand on fait une conception objet on utilise un langage objet.
Faire un super model objet tous beau et l'implémenté en Assembler ou en C n'est pas très judicieux et a faire ...
Pourquoi ? Je suis pas d'accord, quand on fait une grosse application en C, en général, on fait de la conception objet.
Répondre avec citation
Partager