Discussion :

[kromartien]

Bonjour.

Je voudrai savoir si la POO a été inventée comme formalisme pour se départir de certains problèmes techniques tels que la gestion de la mémoire, où si elle a plutôt été inventée pour simplifier les implémentations et la structuration des données.

Je voudrais savoir en fait, en réponse à quels problèmes la POO est-elle devenue une façon de programmer distincte de la programmation en général et dans quel contexte?

Tout cela pour en savoir plus sur la nécessité de posséder un formalisme objet pour un programmeur.

Merci beaucoup pour vos réponses.

[Woufeil]

Salut,

Je te fais un quote de mon cours sur la POO en Perl :

La POO est une méthode de programmation née de réflexions sur la qualité et le coût de la création et de l'entretien d'un programme. En effet, il a été constaté que de 70 à 80% du coût d'un programme provient de la phase de maintenance et non de celle de création pure.
La but de la POO est de réduire ce coût. Pour cela, on a fixé des critères de qualité d'un programme OO. Ils sont au nombre de 4 :
la Validité : respect du cahier des charges
l'Extensibilité : permettre l'ajout de fonctionnalités
la Réutilisabilité : permettre l'utilisation d'un même composant pour différentes applications
la Robustesse : consiste en un traitement des exceptions.

Ca, c'est ce que l'on m'a appris en cours. Après, techniquement parlant, je ne pense pas que l'un des buts de la POO soit de ne plus avoir à gérer la mémoire : un langage de haut niveau comme Perl disposait d'un garbage collector et d'un typage dynamique bien avant de proposer des fonctions permettant de faire de la POO. Je dirais que ce sont deux thèmes indépendants.

[souviron34]

Pour cela, on a fixé des critères de qualité d'un programme OO. Ils sont au nombre de 4 :
la Validité : respect du cahier des charges
l'Extensibilité : permettre l'ajout de fonctionnalités
la Réutilisabilité : permettre l'utilisation d'un même composant pour différentes applications
la Robustesse : consiste en un traitement des exceptions.

Le gars qui t'as enseigné ça est bien ...

Ces 4 critères sont 4 critères de la qualité d'un logiciel. Je ne vois pas en quoi ils sont particulièrement des critères de POO.



Je pense que le fond de la POO est de définir une structuration de langage se rapprochant de l'analyse d'un problème et de sa solution.

En effet, on n'a pas attendu les langages objets pour faire de la POO. Pourquoi ?

Simplement parce que les problèmes ne se posent pas en termes informatiques, mais en termes fonctionnels.

Exemple : un programme de traitement d'image.

• Lecture d'une image A
• Lecture d'une image B
• Addition image A et image B
• Sauvegarde image résultat

On voit vien ici qu'on a une notion d'image, et que l'on fait des opérations sur cet "objet".

Et c'est valable pour une écrasante majorité de problèmes.


Donc on a tenté de définir un paradigme et éventuellement un (et des) langage(s) pour formaliser l'interaction entre la description d'un problème et sa programmation.

Mais soyons précis : comme répété à de nombreuses reprises, la POO n'a pas besoin de langages objet.

Comme dans l'exemple ci-dessus, ce style de programme, bien que de conception POO, peut être fait en Assembleur, en Fortran, en C, en Pascal, bref en n'importe quel langage informatique.

Et si les 4 critères énoncés ci-dessus n'étaient valables que pour la POO, il y aurait eu un nombre incalculable de catastrophes au cours des 50 dernières années...

[Jean-Marc.Bourguet]

Mais soyons précis : comme répété à de nombreuses reprises, la POO n'a pas besoin de langages objet.

Nous sommes d'accord. Mais sans langage objet, faire de la POO est plus compliqué. Les définitions de ce qu'est la POO sont variées et pas toutes d'accord entre elles. Ma perception c'est que c'est un terme qui a été (est encore?) à la mode et comme toujours dans ce genre de cas, il fini à la fois par perdre tout sens (parce que chacun le redéfini en fonction de ses intérêts) et par devenir une religion (parce que ne pas être POO est devenu mal).

Le seul point commun que j'ai trouvé (qui permette en particulier de comprendre des opinions consensuelles comme le fait qu'Ada83 ou Obéron ne sont pas des langages OO tandis qu'Ada95 et Obéron-2 le sont), c'est l'utilisation du polymorphisme d'inclusion combiné avec une surcharge résolue dynamiquement.

Et donc exemple tombe court, ni l'un, ni l'autre n'y sont employés. En le complètant tu peux arriver à une conception qui est OO (par exemple dans sa gestion des formats d'image) ou qui ne l'est pas.

Et oui, il est possible de le faire comme Monsieur Jourdain faisait de la prose, mais c'est beaucoup plus facile quand on en est conscient. Et on peut considérer que l'émergence de la POO résulte de la prise de conscience de l'existance d'un Design Pattern (pour utiliser un autre terme qui a été à la mode bien après) suivit de la décision de créer des langages et des techniques de conception adaptés.

[souviron34]

je suis assez d'accord avec toi sur ce sujet...

Disons qu'on confond usuellement 3 choses :

• 1 Conception orientée objet
• 2 Programmation orientée objet
• 3 Langages objets

Et ce qui m'énerve un peu (tu as dû le remarquer ) dans effectivement la "mode" actuelle, c'est le fait de considérer l'équivalence des 3, et que par conséquent si tu ne connais pas le 3 par exemple, tu ne peux décemment pas faire du 1 ou du 2...


Quand tu dis :

polymorphisme d'inclusion combiné avec une surcharge résolue dynamiquement

pour moi c'est du chinois... Franchement je ne comprend pas ce que ça veut dire. Et c'est bien là-dessus que je te rejoins dans ce que tu dis sur la mode et les définitions et la "religion" etc..

Par contre quand tu dis :

Mais sans langage objet, faire de la POO est plus compliqué

là je ne suis plus...

C'est plus compliqué pour quelqu'un qui n'a pas "l'esprit objet", et que les langages forcent à utiliser la notion.

Mais pour quelqu'un qui maîtrise un langage de programmation, quel qu'il soit, et qui a "l'esprit objet", non ça n'est pas compliqué.


Je pense profondément qu'il faudrait avant tout s'assurer que les programmeurs (mais les profs ne suivent pas non plus ) font de la CONCEPTION orientée objet.

Ceci fait, la PROGRAMMATION orientée objet en découle, et ce quel que soit le langage.

Après, pour les plus "flemmards" (sans vouloir partir de troll ) ou les plus "habitués à la programmation via des outils tout faits" ou les plus "formés à tel ou tel langage", le LANGAGE objet peut être utilisé.

En fait, tout vient de la phrase

"ce qui se conçoit bien s'énonce clairement" ....

[EDIT]

En fait je dirais par rapport au PO :

NON

mais

de la nécessité de la COO

[/EDIT]

[Jean-Marc.Bourguet]

pour moi c'est du chinois...

En gros, utilisation des fonctions virtuelles en C++. Plus en détail:
http://www.bourguet.org/cpp/type.pdf

Par contre quand tu dis :

Mais sans langage objet, faire de la POO est plus compliqué

là je ne suis plus...

C'est plus compliqué pour quelqu'un qui n'a pas "l'esprit objet", et que les langages forcent à utiliser la notion. [/quote]

Il n'y a pas à être forcé (on n'est pas forcé en C++). Mais faire l'équivalent de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct M {
   virtual void f1();
   virtual void f2(int);
};

struct F : M {
   void f1();
   void f2(int);
};

void foo(M* ptr) {
   ptr->f1();
   ptr->f2(42);
}

en C n'est pas si évident que cela. La technique est bien connue, mais l'utiliser sans le support d'un framework bâtit à l'aide de macros, c'est pas le plus naturel. J'ai écrit de tel framework (pour du C et pour de l'assembleur). Mais je continue à préférer un langage conçu avec un support natif.

Après, pour les plus "flemmards" (sans vouloir partir de troll ) ou les plus "habitués à la programmation via des outils tout faits" ou les plus "formés à tel ou tel langage", le LANGAGE objet peut être utilisé.

Tu me places dans quelle catégorie?

A te lire, je me demande parfois si tu as compris ce qu'est la POO.

[Pallando]

Salut
pour mon premier message je vais passer mon tour sur SmallTalk que je connais pas. Par contre concernant les mots magiques Orientés Objets je suis assez d'accord avec Souvrion34, il faut différencier 3 choses

• 1 Conception orientée objet
• 2 Programmation orientée objet
• 3 Langages objets

La première n'a pas été inventée elle est juste naturelle puisque proche de la façon dont on modélise tous les jours. La conception orientées objet existe depuis toujours en fait

La seconde en découle naturellement et est liée à l'évolution de l'informatique. Au fur et à mesure les travaux ont menés à rapprocher la programmation de la conception. Du coup c'est tout naturellement que ce mode de programmation est apparue. Mais là encore on a pas attendu les langages orientés objets pour développer (plus ou moins) comme ça.

Enfin les langages "OO" sont justes les outils issus des étapes précédentes! Assez logiquement les langages se sont adaptés à l'évolution dans la manière de développer. Tous ces langages ne sont certes pas indispensable pour développer en Orienté Objet, mais il faut bien avouer qu'ayant été créés dans cette optique ils sont très efficace!

Maintenant quant à l'utilité de travailler en OO, ayant pris l'habitude je trouve un confort vraiment intéressant, et j'avoue que j'aurais du mal à me passer des fonctionnalités offertes par les langages OO ...mais encore une fois c'est pas synonyme de qualité(ou de rapidité)

[Mat.M]

Mais soyons précis : comme répété à de nombreuses reprises, la POO n'a pas besoin de langages objet.

Comme dans l'exemple ci-dessus, ce style de programme, bien que de conception POO, peut être fait en Assembleur, en Fortran, en C, en Pascal, bref en n'importe quel langage informatique.

c'est évident qu'on puisse faire de la programmation structurée et POO en C voire en assembleur (!)
Mais je préfère prendre les surcouches du C++, de définir des classes.
Cela revient un peu à réduire le débat à C vs C++ qui existe déjà

[Woufeil]

Je pense que tu n'as pas bien compris ce que voulais dire mon prof. Bien entendu que ces quatre critères sont nécessaires s'appliquent à n'importe quel logiciel (j'imagine bien un programme qui ne respecte pas le cahier des charges ). Ce qu'il voulait dire, c'est que la POO permet de faciliter la mise en œuvre de ces critères. Personnellement, je trouve ça tout à fait exact...

[Jean-Marc.Bourguet]

Bonjour. Je voudrai savoir si la POO a été inventée comme formalisme pour se départir de certains problèmes techniques tels que la gestion de la mémoire, où si elle a plutôt été inventée pour simplifier les implémentations et la structuration des données.

D'après Alan Kay (inventeur du terme), une des deux motivations centrales derrière la POO, c'était de trouver une meilleure méthode de modulariser les système complexe.

Je voudrais savoir en fait, en réponse à quels problèmes la POO est-elle devenue une façon de programmer distincte de la programmation en général, dans quel contexte, par qui, comment, pourquoi?

J'ai du mal à répondre à la question, car je ne considère pas la prémisse (à savoir que la POO est une façon de programmer distincte de la programmation en général) comme vraie.

Je vois la POO comme étant l'aboutissement (actuel?) d'un des trois grands paradigme de programmation: la programmation impérative (les deux autres étant la programmation fonctionnelle et la programmation logique).

Tout cela pour en savoir plus sur la nécessité de posséder un formalisme objet pour un programmeur.

C'est une des techniques de conception les plus utilisées -- pas la seule et pas adaptée à tous les problèmes. Ne pas en avoir au moins des notions me semble un fameux trou dans les connaissances pour un programmeur.

[HanLee]

Je vois la POO comme étant l'aboutissement (actuel?) d'un des trois grands paradigme de programmation: la programmation impérative (les deux autres étant la programmation fonctionnelle et la programmation logique).

Est-ce qu'on peut vraiment séparer la POO de la programmation fonctionnelle ?

Je m'explique :

J'ai déjà vu quelques fois des codes où les méthodes étaient programmées en style fonctionnel, c'est à dire en renvoyant un nouvel objet au lieu d'effectuer les modifications sur place.

D'une certaine manière on peut considérer que la POO pratiquée abondamment de nos jours est programmé en style impératif, pour des raisons de performances, mais que ce n'est pas une nécessité.

D'un autre côté, comment créer une copie modifiée d'un objet sans avoir avoir accès à la structure interne de l'objet. Ca reviendrait alors à être obligé d'utiliser des effets de bords sur la copie de l'objet. Et comme souvent on travaille avec une sémantique d'entité en POO, dans ces cas-là, le style fonctionnel (vu de l'extérieur) en POO a-t-il un sens ?

[Jean-Marc.Bourguet]

Est-ce qu'on peut vraiment séparer la POO de la programmation fonctionnelle ?

Un des principes au coeur de la programmation fonctionnelle, c'est d'avoir des fonctions qui calculent des valeurs a partir de leurs parametres uniquement et qui n'ont pas d'autres effets (l'autre grand principe de la programmation fonctionnelle, c'est d'avoir des fonctions qui sont des valeurs manipulables).

Un des principes au coeur de la programmation orientee objet, c'est d'avoir des objets qui ont un etat qui est modifiable.

Plutot incompatible non? Effectivement, une technique utilisee pour contourner la contrainte de ne pas modifier l'etat dans les langages fonctionnels est d'avoir l'etat comme parametre et le nouvel etat faisant partie de la valeur de retour. On peut alors faire de la POO avec un langage fonctionnel, meme pur. Mais j'ai tendance a penser qu'on ne fait plus de la programmation dans le cadre du paradigme fonctionnel.

Ca ne me gene pas du tout, je considere ces techniques comme des outils a employer a bon escient. Vouloir que tout soit objet ou fonction ou je ne sais pas quoi parce qu'on a decrete que c'etait la bonne maniere de programmer, ca ne me convient pas.

[fasteez]

ca dépend si c'est un langage pur ou impur.

la notion d'état représente la notion de temps, bien sur c++, java ont leur histoire dans C, donc assignements impératifs par défaut, mais la question de la performance je sais pas trop (j'aimerais bien mesurer le % de valeurs réellements 'réassignées' comparées aux valeurs invariantes, en mettant de côté les choses comme les IO ihm net disk, par curiosité).

googlisez "SICP" , je trouve que leur approche de la notion d'objet est extremement belle (meme s'ils ne parlent pas de polymorphisme ni d'heritage au début), ils introduisent les couches d'abstraction, l'encapsulation de l'état + opération associées et ca avec une simplicité folle (faut savoir lire un peu scheme par contre).

sinon a mon avis la POO comme on la voit aujourdh'ui n'existe que parce qu'elle aide le dev "industriel" , conceptuellement c'est loin d'etre la panacée selon moi (en meme temps qui suis je pour avoir un avis si tranché lol)

signé un admiratif de lisp qui sait pas faire grand chose en info.

edit: comme cité juste avant, les fonctions comme valeurs du langage c'est un concept fort, et qui va plus loin que les objets je trouve.

[Jean-Marc.Bourguet]

ca dépend si c'est un langage pur ou impur.

Un langage fonctionnel permet d'autre style de programmation que la programmation fonctionnelle. Soit avec un support natif (les langages "impurs" et les lisps en particulier, ce n'est pas pour rien qu'E. Sommet classe Lisp2 dans la famille d'Algol meme si c'est signe a mon avis qu'elle a manque quelque chose), soit en forcant plus ou moins la main (la technique de passer explicitement l'etat) de facont plus ou moins visible (les monades).

googlisez "SICP" , je trouve que leur approche de la notion d'objet est extremement belle (meme s'ils ne parlent pas de polymorphisme ni d'heritage au début), ils introduisent les couches d'abstraction, l'encapsulation de l'état + opération associées et ca avec une simplicité folle (faut savoir lire un peu scheme par contre).

Je doute qu'ils pretendent se limiter a la programmation fonctionnelle.

signé un admiratif de lisp qui sait pas faire grand chose en info.

J'aime beaucoup lisp egalement. Et j'ai deja ecrit par le passe ce que je pensais des techniques qui deviennent des dogmatismes (que ce soit pour la POO ou la programmation fonctionnelle).

comme cité juste avant, les fonctions comme valeurs du langage c'est un concept fort, et qui va plus loin que les objets je trouve.

J'ai ete etonne que ca ne fasse pas partie de ce qui est donne comme tentative de definition dans la FAQ de comp.lang.functional.

Mais bon, on est en train de changer de sujet -- et le format de ce media s'accorde mal de tel changement.

[InOCamlWeTrust]

Un des principes au coeur de la programmation fonctionnelle, c'est d'avoir des fonctions qui calculent des valeurs a partir de leurs parametres uniquement et qui n'ont pas d'autres effets (l'autre grand principe de la programmation fonctionnelle, c'est d'avoir des fonctions qui sont des valeurs manipulables).

Un des principes au coeur de la programmation orientee objet, c'est d'avoir des objets qui ont un etat qui est modifiable.

Plutot incompatible non?

J'apprécie énormément tes interventions, mais là, je suis désolé, tu as presque tout faux.

Objective Caml, langage fonctionnel, implante les objets à la Java (donc avec effets de bords, et héritage avec sous-typage), mais permet aussi de créer des objets entièrement fonctionnels, non modifiables, qui ne sont pas différents des autres objets (en fait, il s'agit d'un opérateur à ajouter dans la valeur de retour des méthodes). On peut dès lors programmer de façon fonctionnelle pure et faire de la programmation objet. C'est malheureusement une caractéristique trop peu connue de ce langage, dont la force se situe dans son approche objet. Des informations ici, au point numéro 13 :

http://caml.inria.fr/pub/docs/manual...manual005.html

Comme quoi...

Ce qui m'agace, pour ma part, c'est que l'amalgame suivant se fasse trop souvent dans la tête des programmeurs :

programmation = pour être bien faut faire comme dans l'industrie = faut faire de la POO = faut faire du Java ou du C ++

Notons aussi qu'en industrie, on faut énormément de conneries (entre autres, Windows !).

edit: comme cité juste avant, les fonctions comme valeurs du langage c'est un concept fort, et qui va plus loin que les objets je trouve.

En Objective Caml, les objets sont des valeurs comme toutes les autres, au même titre que les entiers ou les booléens ; donc oui, tu as raison, on a encore (après 50 ans et l'avènement de LISP) des décennies d'avance sur ce qui se fait en industrie !

[Jean-Marc.Bourguet]

J'apprécie énormément tes interventions, mais là, je suis désolé, tu as presque tout faux.

Objective Caml, langage fonctionnel, implante les objets à la Java (donc avec effets de bords, et héritage avec sous-typage), mais permet aussi de créer des objets entièrement fonctionnels, non modifiables, qui ne sont pas différents des autres objets (en fait, il s'agit d'un opérateur à ajouter dans la valeur de retour des méthodes). On peut dès lors programmer de façon fonctionnelle pure et faire de la programmation objet. C'est malheureusement une caractéristique trop peu connue de ce langage, dont la force se situe dans son approche objet. Des informations ici, au point numéro 13 :

http://caml.inria.fr/pub/docs/manual...manual005.html

Comme quoi...

Je crois que j'ai precise ma pensee dans un autre message. J'ai du mal a considerer que la technique consistant a passer explicitement l'etat et a le retourner soit de la programmation fonctionnelle. C'est une technique utile quand on programme dans un langage "pur", c'est meme une technique utile dans d'autres cas car elle permet de conserver des proprietes interessantes, mais c'est faire rentrer une conception fondamentallement non fonctionnelle dans un moule formellement fonctionnel.

e qui m'agace, pour ma part, c'est que l'amalgame suivant se fasse trop souvent dans la tête des programmeurs:

programmation = pour être bien faut faire comme dans l'industrie = faut faire de la POO = faut faire du Java ou du C ++

Notons aussi qu'en industrie, on faut énormément de conneries (entre autres, Windows !).

En Objective Caml, les objets sont des valeurs comme toutes les autres, au même titre que les entiers ou les booléens ; donc oui, tu as raison, on a encore (après 50 ans et l'avènement de LISP) des décennies d'avance sur ce qui se fait en industrie !

Une chose qui m'agace, c'est le mepris de l'universite par l'industrie et inversement. Pretendre qu'on peut mieux faire sans vouloir tenir compte des contraintes avec lesquelles ca ete fait n'est pas honnete.

[gd_dev]

A mon avis,

La POO répond à la problématique de maintenance dans le cycle de vie de l'application. En effet, sur de gros projet il est pratiquement impossible de documenter toutes les fonctions de l'application en ayant une vue global et pour le développeur qui doit corriger un Bug ou implémenter de nouvelle fonction, il doit pratiquement revoir tous le code par ce qu'il n'ait jamais certain à 100% de l'impacte de ça modif.

La POO favorise la visualisation du système en boîte noire et du coup donne une vision moin abstraite du projet.

Dans la réalité, on n'a pas toujours réussit à mettre en oeuvre cette belle idée. Preuve en est Java avec toutes ces classes, les programmeurs Java me comprendrons.En effet, il arrive souvent qu'un développeur crée une classe qui existe déjà par ce qu'il ne la pas vue ou n'a pas eu le temps de lire la doc et du coup la logique du beau model devient aussi limpide qu'avec d'autres techniques.

Pour répondre à vôtre question, "La nécessité de la Programmation Orientée Objet"
A mon avis, la POO étant à la mode et comme pratiquement tous les languages qui sont sortis depuis 1998 proposent de l'objet, il faut savoir travaillé avec même si on est pas homo objet pensant. C'est un peu comme l'anglais, on y échappe pas.

[gorgonite]

La POO répond à la problématique de maintenance dans le cycle de vie de l'application. En effet, sur de gros projet il est pratiquement impossible de documenter toutes les fonctions de l'application en ayant une vue global et pour le développeur qui doit corriger un Bug ou implémenter de nouvelle fonction, il doit pratiquement revoir tous le code par ce qu'il n'ait jamais certain à 100% de l'impacte de ça modif.

tu ne confondrais pas POO et programmation modulaire ?

[gd_dev]

tu ne confondrais pas POO et programmation modulaire ?

Non, je confond pas. La programmation modulaire ne répond pas a toutes les questions de la problématique de la maintenance. D'autre part, il est évident que les différents style de programmation réponde plus ou moin au même problème.

La question étant de quel besoin est né la POO, je répond qu'a mon avis c'est la problématique de la maintenance.

[gorgonite]

La question étant de quel besoin est né la POO, je répond qu'a mon avis c'est la problématique de la maintenance.

j'aurais plutot dit d'un délire de spécialistes de la théorie des langages au fond de leur labo... donc très éloigné de tout ce que les industriels auraient pu vouloir