Discussion :

[kromartien]

Je crois que j'ai vu l'intérêt pratique de l'héritage aujourd'hui.

[Woufeil]

L'écriture [...]signifie que F2 hérite de F , c'est ça ? c'est à dire contient F, mais n'est pas du même type.. (surensemble)

Oui, c'est ça.

L'héritage permet de définir des relations « est un » (IS A) entre plusieurs classes. C'est la notion de classification. Ainsi, on peut dire que l'humain est un mammifère, qui est lui même un animal. En tant que mammifère, l'homme hérite des propriétés des mammifères, comme le fait d'avoir quatre membres, des poils... Il hérite aussi des méthodes de cette classe. Ainsi un homme comme tout mammifère peut bouger. A cet héritage la classe humain ajoute des particularités, comme la méthode « parler », ou la variable nationalité. On dit que la classe humain hérite de la classe mammifère. Mammifère est la classe parente et humain est la classe fille. Comme un humain est un mammifère, on peut utiliser le premier à la place du second (et pas l'inverse, un mammifère n'étant pas un humain). Ainsi, si un sous programme attend comme argument un mammifère, on peut lui passer un humain sans qu'il n'y est de problèmes.

Plus de précision sur la surcharge de méthode et le polymorphisme :

Une classe fille peut redéfinir les méthodes d'une classe parente. Ainsi, la classe mammifère a une méthode se déplacer mais la classe cheval peut avoir envie de surcharger (redéfinir) cette méthode en précisant qu'un cheval peut marcher au pas, au trot et au galop. On dit que la méthode marcher de mammifère a été surchargée par celle de la classe cheval. Mais que ce passe-t-il si une fonction qui attend un mammifère comme argument reçoit un cheval et que cette fonction appelle la méthode se déplacer ? Dans ce cas la méthode appelée sera la méthode redéfinie dans la classe cheval. Mais si la fonction reçoit un humain et que cette dernière classe n'a pas redéfinie la méthode se déplacer, la méthode appelée sera celle de la classe mammifère. Cette propriété de choisir quelle méthode appeler en fonction de l'argument passé à la fonction s'appelle le polymorphisme.

[Jean-Marc.Bourguet]

Même sans utiliser deux fonctions virtuelles, ce que je ne vois pas en C, c'est comment régler ce problème :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Class C1 {
    virtual void f ();
};

Class C2 : C1 {
    void f ();
};

void foo (C1 objet)
{
    objet.f(); //Sans dynamisme, ce sera toujours la méthode de C1 qui sera utilisée
}

Je ne vois vraiment pas comment appeler la bonne méthode sans le mot clé virtual...

Tu peux utiliser des pointeurs sur fonction. Mais la methode de Souviron34 est un peu trop simple a mon gout.

[Jean-Marc.Bourguet]

Peux-tu expliciter en français ce que tu veux faire ? Ne connaissant pas C++, je ne comprends pas exactement

J'ai simplement utilise une autre classe derivee que celle que tu connaissais (et j'ai un probleme, j'ai oublie d'initialiser un membre).

(et si je comprend, je ne vois pas en quoi ma réponse à ton exemple a des problèmes).

Ta reponse ne passe aucun objet aux fonctions pour commencer.

Et donne-moi un exemple d'héritage multiple, et on va voir

Deux exemples en un seul:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
#include <stdio.h>

struct b {
    b(): i_(0) {}
    b(int i): i_(i) {}
    void f() { printf("%d\n", i_); }
private:
    int i_;
};

struct i1: virtual b {
    i1(int i): b(i) {}
    void g1() { f(); }
};

struct i2: virtual b {
    i2(int i): b(i) {}
    void g2() { f(); }
};

struct i3: b {
    i3(int i): b(i) {}
    void g3() { f(); }
};

struct f: i1, i2,  i3 {
    f(): i1(1), i2(2), i3(3) {}
};

struct b2 {
    void f() { printf("b2::f()\n"); }
};

struct b3 {
    virtual void g() { printf("b3::g()\n"); }
};

struct f2: b2, b3 {
    virtual void g() { f(); }
};

int foo(b3& x) {
    x.g();
}

int main() {
    f x;
    x.g1();
    x.g2();
    x.g3();
    f2 y;
    foo(y);
}

avec pour resultat d'execution:

Code :

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

1
2
3
4
0
0
3
b2::f()

ET ?? Je ne vois pas en quoi, dans tout ce que j'ai dit plus haut, on ne peut pas considérer que l'on peut faire de l'héritage en C..

Je n'ai jamais ecrit cela. J'ai ecris qu'une conception OO sans heritage etait degeneree, quelle que soit le langage utilise pour l'implementer. La base de ta technique me convient tres bien. Simplement pour l'utiliser en pratique il faut des parametres en plus, un peu plus de casts, ajouter des niveaux de structures... un certain nombre de chose qui font qu'elle est delicate a utiliser et fragile car on perd la verification des types du compilateur a cause des casts. Voir le message 15 sur ce fil.

Et je ré-itère que les notions d'héritages, et de ce que vous semblez appeler "polymorphisme dynamique" (qui, comme je le répète pour moi sont des mots dont je ne comprend pas la signifcation telle quelle car ils supposent une "formation" adaptée)

Je ne pense pas que j'ai employe le terme "polymorphisme dynamique". Je ne connais pas de sens precis a cette expression, et ce qu'elle pourrait recouvrir englobe des choses qui n'ont pour moi rien a voir avec l'OO.

J'ai l'impression qu'un probleme que nous avons dans la communication est que j'utilise des termes qui ont un sens technique plus ou moins precis que tu comprends en extrapolant le sens commun. Ce dernier permet generalement d'avoir une idee de quoi il s'agit, mais pas des limites. Et quand on te dit que le sens technique est plus precis et n'englobe pas des choses que le sens commun pourrait facilement croire qu'elles sont inclues, tu n'as pas l'air de le comprendre.

Conception Orientee Objet et Langage Oriente Objet font partie de ces termes.

sont courants EN DEHORS DES LANGAGES OBJETS (bon, courant peut-être pas, mais suffisamment utilisés pour ne pas être exceptionnels).

Je n'ai jamais ecrit le contraire. Il me semble meme avoir deja signale que j'ai ecrit des macros pour faire de l'OO en C comme en assembleur.

Et je pourrais meme aller plus loin, les langages OO type statiquement ont tendance a limiter les utilisations potentielles a ce qui est utile pour faire de l'OO pour gagner la possibilite de verifier statiquement la validite de certains invariants.

Je dirais que le seul langage "objet" réel que j'ai rencontré (je n'ai pas fait se SmallTalk) (et bien que l'on ne le dénomme pas de cette manière) a été Prolog. Là oui la traduction n'est pas évidente dans un autre langage.

Prolog n'est pas un langage objet; son modele de calcul est trop different. Un langage oriente objet suppose qu'il y a des objets qui ont un etat. Prolog n'a pas reellement de notion d'etat.

Jean-Marc, j'aimerais que tu explicites un peu cette phrase stp :

Ce foutu systeme qui n'est pas capable de citer a deux niveaux m'enerve.

L'heritage n'est pas reellement necessaire. La possibilite d'avoir des objets qui sont de plusieurs types l'est. Et la possibilite d'avoir une resolution de surcharge tenant compte des aspects dynamiques de l'objet et pas uniquement son type statique.

Car si je le comprend correctement, je ne vois pas en quoi cela serait impossible de manière simple (mais pas forcément facilement compréhensible pour un néophyte) en C.

Je crois que j'ai trouvé..

En fait, je pense que notre point d'achoppement (et je reviens à ce que je disais plus haut) est le fait que cela soit facile ou non à comprendre par des débutants ou quasi-débutants..
[/Edit][/QUOTE]

Non, notre point d'achoppement est sur la simplicite. Tu peux traiter des cas particuliers de maniere simple, traiter le cas general n'est pas si simple que cela (c'est pas horriblement complique non plus, mais si j'ai a le faire en C, je prefere cacher tout cela dans un framework).

[Jean-Marc.Bourguet]

Personnellement, je n'ai jamais vu de polymorphisme dans un langage non OO.

La genericite est une forme de polymorphisme qui n'a rien avoir avec l'OO.

Je sais, les specialistes de l'OO ont tendance a restreindre polymorphisme a celui qu'ils employent et ceux de la genericite de meme. Mais depuis son introduction dans ce contexte dans les annees 70, polymorphisme est employe pour plus de choses, y compris les conversions implicites.

[Jean-Marc.Bourguet]

par "surcharger" tu veux dire "remplacer" c'est ça ?

La surcharge est une forme de polymorphisme ou le meme nom designe plusieurs fonctions; le choix etant effectue suivant le type des parametres. En C++, on trouve la surcharge de 3 manieres:
- la specialisation implicite des templates -- passons;
- une forme de surcharge qui utilise le type statique des parametres, que le C++ appelle la surcharge:

Code :

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

1
2
3
4
5
void f(int);
void f(double);
...
f(4.3); // appelle le second f
f(4); //appelle le premier f

- une forme de surcharge resolue dynamiquement en n'utilisant qu'un parametre special (les autres parametres peuvent resoudre la surcharge de maniere statique), les fonctions ainsi surchargees sont les membres virtuels

Code :

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

1
2
3
4
5
6
7
8
9
10
struct s1 {
virtual void f();
};

struct s2: s1 {
virtual void f();
};
void foo(s1* s) {
   s->f();
}

Ici s est un parametre privilegie qui sert a la resolution. Il peut pointer sur un s1 auquel cas le premier f sera appele, ou sur un s2 (le second f sera appele) ou sur un autre descendant de s1 (le f qui sera appele dependra du descendant, pourra etre le premier si le descendant ne supplante pas f).

[gege2061]

car on perd la verification des types du compilateur a cause des casts.

GTK+ propose des macro pour vérifier qu'un objet est bien du type attendu.

Mais comme tu le dis, y a quelques ligne de code en plus pour créer une classe :

Code c :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#ifndef H_GTK_SDL_NJ_0405071201
#define H_GTK_SDL_NJ_0405071201
 
#include <gtk/gtkwidget.h>
 
G_BEGIN_DECLS
 
#define GTK_TYPE_SDL            (gtk_sdl_get_type ())
#define GTK_SDL(obj)            (GTK_CHECK_CAST ((obj), GTK_TYPE_SDL, GtkSDL))
#define GTK_SDL_CLASS(klass)    (GTK_CHECK_CLASS_CAST ((klass), GTK_TYPE_SDL, GtkSDLClass))
#define GTK_IS_SDL(obj)         (GTK_CHECK_TYPE ((obj), GTK_TYPE_SDL))
#define GTK_IS_SDL_CLASS(klass) (GTK_CHECK_CLASS_TYPE ((klass), GTK_TYPE_SDL))
 
typedef struct _GtkSDL GtkSDL;
typedef struct _GtkSDLClass GtkSDLClass;
 
struct _GtkSDL
{
  GtkWidget widget;
};
 
struct _GtkSDLClass
{
  GtkWidgetClass parent_class;
};
 
GtkType gtk_sdl_get_type (void);
GtkWidget *gtk_sdl_new (void);
 
G_END_DECLS
 
#endif /* H_GTK_SDL_NJ_0405071201 */

Code c :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#include "gtksdl.h"
 
static void exl_document_destroy (GtkObject *object)
{
  ExlDocumentClass *klass;
 
  g_return_if_fail (object != NULL);
  g_return_if_fail (EXL_IS_DOCUMENT (object));
 
  klass = gtk_type_class (gtk_widget_get_type ());
  if (GTK_OBJECT_CLASS (klass)->destroy)
  {
    (*GTK_OBJECT_CLASS (klass)->destroy) (object);
  }
}
 
static void gtk_sdl_class_init (GtkSDLClass *class)
{
  GtkObjectClass *object_class;
 
  object_class = GTK_OBJECT_CLASS (class);
  object_class->destroy = gtk_sdl_destroy;
}
 
static void gtk_sdl_init (GtkSDL *sdl)
{
  g_return_if_fail (sdl  != NULL);
  g_return_if_fail (GTK_IS_SDL (sdl));
}
 
G_DEFINE_TYPE (GtkSDL, gtk_sdl, GTK_TYPE_WIDGET)
 
GtkWidget *gtk_sdl_new (void)
{
  GtkSDL *this = NULL;
 
  this = gtk_type_new (gtk_sdl_get_type ());
  return GTK_WIDGET (this);
}

En C++ :

Code c :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class GtkSDL : GtkWidget
{
  public:
    GtkSDL ();
    ~GtkSDL ();
};
 
GtkSDL::GtkSDL ()
{
}
 
GtkSDL::~GtkSDL ()
{
}

[souviron34]

Salut

je n'ai pas eu le temps de regarder, mais je regarderais vos exemples ..

Merci à Jean-Marc et à Woufeil des explications....

Pour l'instant je n'ajouterais qu"un point (et comme tu dis exactement Jean-Marc c'est là que ça achoppe) :

je ne prétend pas qu'il soit facile de refaire en C toutes les constructions d'un langage comme le C++.

Ce que je prétend, et c'est pour ça que je parlais "d'écrire en texte clair", c'est que la manière précise de résoudre un besoin découlant d'une certaine analyse , n'est pas forcément en langage objet, mais que la conception est en "objet" (si tu veux, JM, dégénérée, mais je ne pense pas).

Ce que je pense est que au contraire, comme tu le dis toi-même d'ailleurs, l'emploi de termes TECHNIQUES précis issus d'un certain formalisme "préformatte" la réponse au problème posé.


Et que donc ce qui pour moi est de la "Conception Objet", c'est à dire isoler dans l'analyse d'un problème des entités ayant des atttributs et des comportements communs, éventuellement dérivés d'autres, est utilisé de manière biaisée en y introduisant comme je le disais du "préformattage" technique, ce qui fait qu'une fois ce pré-formattage fait, évidemment la chose collant le plus à ça est un langage qui recouvre ce formalisme.

Je n'ai pas eu le temps encore comme dis plus haut d'approfondir vos 2 exemples, mais si vous voulez mon point c'est : "à quel problème répond cette construction ?".

Une fois le problème posé en termes généraux , là on peut envisager différentes approches, et éventuellement différentes implémentations, certaines plus longues que d'autres.

Voilà c'est tout pour aujourdhui

A+

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

[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]

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.

[Négrier]

Le maître mot de la programmation à objets est la réutilisabilité par dérivation.

Que ce soit en programmation impérative (C), fonctionnelle (Lisp) ou logique (Prolog) le développeur doit coder de nouvelles applications (fonctions partout définies comme il se doit) en utilisant celles qui sont mises à sa disposition (que je qualifierai de "couche applicative").

La couche "orientée objet" a pu être ajoutée pour chacun de ces trois types de langages (C->C++, LISP -> ObjVLisp, Prolog -> ObjVLog), éventuellement de façon artisanale par les utilisateurs des langages de base qui "sentaient" la nécessité de l'objet.

Losqu'il s'agit d'utiliser des objets existants pour définir ses applications alors la "couche objet" ne se comporte pas très différemment de la "couche applicative". Mais l'essentiel de la programmation objet consiste à dériver des objets (classes) existant(e)s.

Pour effectuer son travail le développeur dispose d'un ensemble logiciel gigantesque (les frameworks standard pour commencer) dans lequel se trouve l'objet particulier (à quelque chose près) dont il a besoin pour ses développements. C'est la programmation objet (polymorphisme) qui va lui permettre de combler, avec l'effort minimum nécessaire, la différence epsilonesque entre l'objet existant et l'objet dont il a besoin.

A contrario une des difficulté de la POO est la capacité à développer des objets qui soient dérivables en plus d'être réutilisables, et je crois qu'il s'agit là de deux "métiers" différents. Utiliser des langages purement objet (Smalltalk, Java) ne garantit pas la dérivabilité des objets (ou composants) que l'on fabrique à moins que l'on ait réellement pris en compte la possibilité qu'ils puissent l'être.

[super_navide]

La Programmation Objet est une Evolution de langage pour faciliter la modelisation de problème complexe.
Elle fait appel a des notions intuitive qui sont tiré du langage naturel.

De plus il faut raisonner sur la notion de langage
il y a
le langage de naturel
le langage assembleur
le langage objet
le langage fonctionnel
le langage mathématique


tous tende et ont comme but de répondre a un besoin humain celui de comprendre notre environement et notre esprit

le langage fondamental est celui des matématiques

La POO tend a lier langage naturel ,langage de programation et langage matématique .
Ce qu'il manque c'est une unique langage universel

[InOCamlWeTrust]

Ce qu'il manque c'est une unique langage universel

L'anglais ?

[kromartien]

En fait pour ce qui s'agit du langage universel, je crois que il faut bien préciser que c'est complétement utopique comme concept. Le langage universel (qui regrouperait les maths, la programmation, la physique nucléaire, la philosophie, etc) aurait alors une complexité bien trop importante pour être utilisable.

Le langage c'est avant tout un moyen de formaliser les concepts, et lorsqu'il s'agit de représenter des concepts dans des champs d'application trop disparates, vouloir utiliser un seul langage pour tout paraît vraiment trop difficile.

J'imagine que c'est la même chose pour les langages de programmation, c'est à dire que ils sont utilisés pour leurs propriétés particulières dans des champs d'applications particuliers, et je crois que la Programmation Orientée Objet ne fait pas exception, dans el sens où elle a sûrement été la réponse à la nécessité d'une formalisation et/ou d'une meilleure utilisation des langages de programmation (sémantique complexe, donc possibilité de traiter avec des objets plus élaborés tout en obtenant un gain de temps dans l'utilisation du langage) .

Il me semble qu'effectivement c'est la raison d'être des langages de programmation, et la question essentielle que je me posais au sujet de la Programmation Orientée Objet, c'est bien celle de savoir pour quels champs d'application (donc en réponse à quel besoin spécifique) la POO a-t-elle vu le jour, avec ses propriétés telles qu'elles sont utilisées actuellement.

[Angelus21]

Personnellement, je viens d'une école où m'a été enseigné en majorité de la Conception Orientée Objet. Qui plus est, pour illustrer les concepts appris on s'est surtout basé sur Java.

On me dira surement que ne connaitre que cet aspect de la programmation est bien réducteur, et je le concède.
Cependant, je peux peut être apporter mon point de vue sur tout ça

Pour être concis, la Conception Orientée Objet est juste une façon de modeliser son environnement, de créer un modèle métier. C'est une façon de voir, rien de plus.
Mais se dire qu'un boulon de 50 a quand meme des propriétés en commun avec un boulon de 100, et qu'il se vissera de la même façon, je trouve le concept intéressant et simple de compréhension.
"Simple de compréhension", c'est bien là tout l'intéret. Tout ceci n'existe que pour simplifier la modélisation de systèmes complexes !

En effet, corrigez moi si je me trompe, mais la COO se verra associée à des Patterns qui auront toujours un objectif de simplification, d'évolutivité et de modularité.

Je suis aussi d'accord avec Jean-Marc Bourguet qui trouve dérangeant de vouloir que tout soit objet ou tout fonctionnel. Les deux sont complémentaires, et à utiliser à bon escient.
D'ailleurs, des langages orientés objet tel que java, C# etc, proposeront toujours l'utilisation de classes static dont un intéret sera de proposer des fonctions prenant des parametres, et de retourner des valeurs.

Après, je pense que les langages dits "modernes" objets ont aussi été conçus toujours dans un soucis de rapidité de développement. Après tout, on est dans un monde de rentabilité, où tout est mis en oeuvre pour faciliter la vie !!

Parce que le tout objet, il ne faut pas l'oublier, est aussi vieux que le C : SmallTalk en est la preuve.

[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 ?