Qu'est-ce que la programmation orientée objet (POO) ?

Bonjour,

J'ai parcouru plusieurs ouvrages à la recherche d'une définition simpliste et fluide du concept orienté objet. Malheureusement toutes celles que j'ai rencontré sont trop high-tech et nécessitent un niveau avancé dans le domaine pour les appréhender.

Quelqu'un pourrait-il m'expliquer de façon simple le concept orienté objet, puis la programmation orientée objet (POO) et me montrer la différence qui existe entre cette dernière et la programmation classique ?

Merci d'avance.

Qu'est-ce que tu appelles "programmation classique" ?

Est-ce que tu as compris la différence entre une classe et un objet ?

C'est pas ce que tu crois. Quand je dis programmation classique je ne fais pas allusion au concept de classe, mais plutôt à la programmation qui fait abstraction des concepts de classe ou encore d'objet.

Citation:

---

Envoyé par soslab

Quand je dis programmation classique je ne fais pas allusion au concept de classe, mais plutôt à la programmation qui fait abstraction des concepts de classe ou encore d'objet.

---

Donc, de la programmation impérative, avec des fonctions, des structures et c'est tout ? https://fr.wikipedia.org/wiki/Progra...mp%C3%A9rative

Revoyez ma question ? Je n'ai pas demandé un lien vers la programmation impérative ! Ce que je veux, c'est qu'on me dise c'est quoi la programmation orientée objet. J'espère que vous me compreniez

Citation:

---

Envoyé par soslab

C'est pas ce que tu crois. Quand je dis programmation classique je ne fais pas allusion au concept de classe, mais plutôt à la programmation qui fait abstraction des concepts de classe ou encore d'objet.

---

Ma première question ne faisait pas référence aux classes. J'ai été maladroit de mélanger mes deux questions désolé. Ce que je voulais dire c'est que tu sous-entends qu'il y aurait une programmation classique, au sens de "la plus répandue", or c'est probablement la programmation orientée objet qui est la plus répandue de nos jours.

Mais bref, ma deuxième question tient toujours : "Est-ce que tu as compris la différence entre une classe et un objet ?".

Ça fera une base de discussion.

Citation:

---

Envoyé par soslab

Revoyez ma question ? Je n'ai pas demandé un lien vers la programmation impérative ! Ce que je veux, c'est qu'on me dise c'est quoi la programmation orientée objet. J'espère que vous me compreniez

---

Il t'a donné ce lien parce que historiquement c'est ce paradigme qui peut être considéré comme le classique, il a longtemps été dominant.

Au départ, c'était la programmation listing (COBOL, BASIC) : on exécutait ligne par ligne (de la première à la dernière).
On s'est aperçu que certains traitements étaient répétés : donc on a extrait ces traitements pour faire des fonctions/ procédures pour éviter de copié-collé du code. C'est la programmation procédurale (C, JavaScript)
Maintenant je ne sais pas pourquoi on a collé au modèle mathématiques :koi: : plusieurs entrées, 1 seul résultat.

Ensuite, on a associé ces traitements (qu'on appelle des messages) à des états : c'est un objet.
Édit: el_slapper a faire une bonne remarque :P : on s'est aperçu que certaines fonctions/ procédures agissaient sur les mêmes variables, et donc on les a associées.
Par exemple, un objet bulb (ampoule) a un état allumé, et comme messages turn_on, turn_off.
Et indirectement :whistle:, on s'éloigne du fonctionnement ligne par ligne d'un ordinateur - on a un ensemble d'objets qui vont s'envoyer des messages.

Mais c'est plus compliqué que cela :mrgreen: :

• il y a 2 types de POO : par héritage, par prototype
• il y a la POO pure ou pas - s'il y a ou pas une classe racine
• c'est une forme de polymorphisme : wikibooks : Programmation/Programmation orientée objet/Polymorphisme
• c'est une relation "is" contrairement à l'agrégation/ la composition qui est une relation "has"
• Plusieurs concepts s'y greffent : encapsulation, polymorphisme multiple, interface, traits, ...

Bonjour,

Citation:

---

Envoyé par soslab

Quelqu'un pourrait-il m'expliquer de façon simple le concept orienté objet, puis la programmation orientée objet (POO) et me montrer la différence qui existe entre cette dernière et la programmation classique ?

---

Je lis dans un de tes messages que tu débutes en langage C. Du coup, par programmation classique, je présume que tu parles du procédural. Je ne connais pas ton niveau en C, mais je vais essayer de décrire la POO en partant du C.

En POO, il y a deux grands principes :

• l'encapsulation, qui n'est pas un concept exclusif à la POO, mais qui est obligatoire dans la POO et
• l'héritage, qui est un concept très spécifique à la POO.

En général, on cite aussi le polymorphisme comme 3e principe. Mais, dans la pratique, le polymorphisme de la POO se réduit à celui de l'héritage.

Pour illustrer l'encapsulation, voici un exemple sans encapsulation : imagine qu'un certain fichier ".h" définit une structure String :

Code:

---

1 2 3 4 5 6

typedef struct String { char* m_ptr; // pointe vers le tas size_t m_size; size_t m_capacity; } String;

---

Tu manipules directement les champs de ta structure String un peu partout dans ton programme. Et un jour, tu te rends compte qu'il vaudrait mieux changer l'implémentation pour stocker la chaîne sur place au lieu de la stocker dans le tas quand elle est petite (Small String Optimization).

Tu changes alors la définition de la structure :

Code:

---

1 2 3 4 5 6 7

typedef struct String { char* m_ptr; // pointe vers m_buffer ou vers le tas char m_buffer[32]; size_t m_size; size_t m_capacity; } String;

---

Et là, tu te dis : « Et merde, je dois mettre à jour du code éparpillé un peu partout dans mon programme. »

Pour éviter cela, il aurait fallu restreindre la liste des fonctions qui ont le droit d'accéder directement aux données de la structure :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

typedef struct String { // Seules les fonctions déclarées dans le fichier présent ont le droit de manipuler directement ces variables ! char* m_ptr; // pointe vers le tas size_t m_size; size_t m_capacity; } String;   String_NewEmptyString(String* self);   String_Destroy(String* self); // fait free(self->m_ptr)   String_Append(String* self, String const* other);   // Autres fonctions...

---

Ainsi, le jour où tu voudras changer le contenu de ta structure, ce sera plus facile, car il te suffira de mettre à jour le code local sans avoir besoin de toucher le reste du programme.

Le fait de restreindre la manipulation directe des données d'un type à une liste de fonctions rattachées à ce type s'appelle l'encapsulation. En POO, ce type est alors appelé une classe et les fonctions ratachées à ce types sont appelées les méthodes de la classe.

Je viens de donner un exemple dans le cas de l'optimisation, mais il y a aussi d'autres intérêts, comme concentrer à un seul endroit du programme certaines dépendances à des bibliothèques externes.

En C, tu ne peux imposer l'encapsulation que par convention (à moins d'utiliser une technique qui s'appelle les pointeurs opaques, mais c'est un autre sujet). Dans d'autres langages, tu peux contrôler directement à la compilation que seules certaines fonctions ont accès aux données de la structure.

De manière générale, on dit que tout ce qui ne doit pas être accessible au code extérieur est privé. Les données de la structure ne sont d'ailleurs pas les seules choses privées. On peut aussi définir des méthodes privées.

L'héritage est plus compliqué à expliquer.

En programmation, il y a une notion qu'on appelle polymorphisme qui consiste à écrire un code qui fonctionne pour plusieurs types à la fois. Il y a plein de manières de faire du polymorphisme.

Le problème du langage C est qu'il est très limité pour ce genre de chose. On peut faire des bricolages avec des pointeurs de fonction ou des macros, mais ce n'est pas pratique. Du coup, des langages de plus haut niveau supportent des fonctionnalités qui facilitent le polymorphisme.

En programmation orientée objet, on utilise l'héritage qui est une forme de sous-typage.

Concrètement, on définit un type de base qui possède des méthodes pas forcément définies, par exemple un type LoggerBase qui a une méthode abstraite pour loguer. On définit ensuite des sous-types du type de base pour lesquels ont choisit ce que fera la méthode qui logue. Par exemple, on peut définir un type LoggerDeriv qui écrit dans un fichier via un FILE*, CountingLogger qui compte le nombre de fois qu'on lui ordonne de loguer, NullLogger qui ne fait rien, ThreadSafeLogger qui peut loguer dans un fichier de façon thread safe, etc. En POO, les sous-types sont appelés des classes dérivées et on dit qu'ils dérivent de la classe de base.

On peut écrire du code qui travaille directement avec un pointeur de type LoggerBase* sans connaître les sous-types. Cela permet d'écrire un code qui marche d'un coup avec tous les sous-types de LoggerBase, même les sous-types qui n'existent pas encore.

Ensuite, on peut appeler ce code avec un objet dont le type est un sous-type de LoggerBase. Pour implémenter ce genre de chose en C, on peut faire des bricolages avec des structures de pointeurs de fonctions (appelées tables virtuelles) :

Code:

---

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 54 55 56 57 58 59 60 61 62

#include <stdio.h>   typedef enum { LoggerLevel_Error, LoggerLevel_Warning, LoggerLevel_Info, LoggerLevel_Debug } LoggerLevel;   // Classe de base (type parent) :   struct LoggerVTable;   typedef struct LoggerBase { struct LoggerVTable* m_vtable; // pointeur vers la table virtuelle } LoggerBase;   typedef struct LoggerVTable { // Dans cet exemple, il n'y a qu'un seul pointeur de fonction. // Mais, dans le cas général, une table virtuelle peut en avoir plusieurs. void(*m_log)(LoggerBase* self, const char* msg, LoggerLevel level); } LoggerVTable;   void LoggerLog(LoggerBase* self, const char* msg, LoggerLevel level) { self->m_vtable->m_log(self, msg, level); }   // Classe dérivée (sous-type) :   typedef struct LoggerDeriv { LoggerBase super; FILE* m_file; } LoggerDeriv;   void LoggerDerivLog(LoggerDeriv* self, const char* msg, LoggerLevel level) { fprintf(self->m_file, "%s\n", msg); }   void LoggerDerivLogWithCast(LoggerBase* self, const char* msg, LoggerLevel level) { LoggerDerivLog((LoggerDeriv*) self, msg, level); }   LoggerVTable loggerDerivVTable = { &LoggerDerivLogWithCast };   void LoggerDerivCtor(LoggerDeriv* self, FILE* file) { self->super.m_vtable = &loggerDerivVTable; self->m_file = file; }   // Démo :   int main() { LoggerDeriv logger; LoggerDerivCtor(&logger, stdout); LoggerBase* loggerPtr = &logger.super;   // Code qui travaille avec un LoggerBase*, sans savoir que le type réel de l'objet est LoggerDeriv : LoggerLog(loggerPtr, "Object oriented programming.", LoggerLevel_Debug);   return 0; }

---

En C, c'est hyper verbeux. Par contre, dans d'autres langages, on a du sucre syntaxique pour pouvoir faire ce genre de chose avec des pavés de code moins grands.

L'héritage a les caractéristiques suivantes :

• Le polymorphisme par héritage se base une relation de sous-typage. Ce n'est pas le cas de tous les polymorphismes. Par exemple, en duck typing, il n'y a pas de sous-typage et, en programmation générique, il n'y a pas toujours de sous-typage.
• Là où on définit le sous-type, on doit mentionner le type parent. Par exemple, dans la définition de LoggerDeriv, il y a un membre de type LoggerBase. Ce n'est pas systématique en dehors de l'héritage. Par exemple, avec les traits du Rust et les type classes du Haskell, on peut définir un type parent a posteriori, hors de la définition du type qui en sera un sous-type.
• Le type parent peut avoir des données autres que le pointeur vers la table virtuelle, même si ce n'est pas le cas dans mon exemple. Alors, le sous-type récupère toutes les données du type parent.

Les notions de duck typing, de programmation générique, de traits et de type classes ne vont pas te parler, mais il faut juste retenir que l'héritage de la POO n'est pas le seul moyen de faire du polymorphisme.

Pour revenir à l'encapsulation, la POO définit les 3 niveaux de visibilité suivants :

• Ce qui n'est accessible que par la classe en cours est privé.
• Ce qui n'est accessible que par la classe en cours et ses classes dérivées est protégé.
• Ce qui est accessible à tout le monde est public.

Il reste encore d'autres choses à savoir sur la POO, comme la différence entre une méthode statique et une méthode non statique, mais mon message est déjà long.

Citation:

---

Envoyé par Marco46

Mais bref, ma deuxième question tient toujours : "Est-ce que tu as compris la différence entre une classe et un objet ?".

Ça fera une base de discussion.

---

Bonjour Marco46,

Je ne sais tout de même pas pourquoi tu insistes tant à ce que je te fasse la différence entre une classe et un objet. Qui plus est, pourquoi ça fera une base de discussion ? Est-ce une sorte de challenge que tu me lances ? Pourtant je t'ai juste demandé de m'aider en répondant à la question que j'ai postée. Quoique je m'en vais quand même te répondre.

Pour faire simple, un objet est une abstraction ou une chose qui a un sens dans le contexte du système à modéliser. Chaque objet a une identité et peut être distingué des autres sans considerer à priori les valeurs de ses propriétés.

Un classe décrit un groupe d'objets ayant les mêmes propriétés (attributs), un même comportement (opération) et une sémantique commune (domaine de définition).

Satisfait ?

Citation:

---

Envoyé par soslab

Je ne sais tout de même pas pourquoi tu insistes tant à ce que je te fasse la différence entre une classe et un objet. Qui plus est, pourquoi ça fera une base de discussion ? Est-ce une sorte de challenge que tu me lances ? Pourtant je t'ai juste demandé de m'aider en répondant à la question que j'ai postée. Quoique je m'en vais quand même te répondre.

---

Parceque c'est le point de départ. Tout ce qu'a dit Pyramidev est fort juste, mais ne vient qu'après. En objet, on code des classes, et quand ces classes se matérialisent avec des données, ça devient des objets. Ca a tout un tas de conséquences(qu'effleure Pyramidev).

Citation:

---

Envoyé par soslab

Pour faire simple, un objet est une abstraction ou une chose qui a un sens dans le contexte du système à modéliser. Chaque objet a une identité et peut être distingué des autres sans considerer à priori les valeurs de ses propriétés.

Un classe décrit un groupe d'objets ayant les mêmes propriétés (attributs), un même comportement (opération) et une sémantique commune (domaine de définition).

Satisfait ?

---

C'est rigolo, tout le monde fait la relation dans l'autre sens. Ca ne rend pas ta définition fausse pour autant, c'est juste rigolo et inhabituel de voir quelqu'un qui part de l'objet pour aller vers la classe.

Par contre, parler d'un objet comme une abstraction, euh, comment dire..... Rien de plus concret, dans la machine, qu'un objet : c'est un agrégat de données qui suit la structure et les comportements qui ont été définis dans sa classe. Il peut en effet y en avoir plusieurs qui collent à la même classe, comme tu le dis.

Moi, ma définition de la POO, c'est que c'est juste une autre manière de stocker le code : au lieu de mettre d'un coté les structures de données et de l'autre le code qui va agir sur les données contenues dans ces structures(comme en procédural), on va mettre le code qui agit sur lesdites données dans la structure elle-même. Ce qui change complètement la manière de penser. Il y a des milliards de définitions différentes, mais celle-ci est celle qui me convient. Les autres sont justes aussi, hein, et plus tu en liras de différentes, plus tu pigeras la différence.

Bonjour Pyramidev,

Merci pour ton intervention. Quoique j'ai étudié déjà la plupart des concepts dont tu as fais mention dans ton message en UML 2. Mais je dois admettre que la manière avec laquelle tu les as abordé m'a permis de compléter ma connaissance de ceux-ci.

Citation:

---

Envoyé par el_slapper

C'est rigolo, tout le monde fait la relation dans l'autre sens. Ca ne rend pas ta définition fausse pour autant, c'est juste rigolo et inhabituel de voir quelqu'un qui part de l'objet pour aller vers la classe.

Par contre, parler d'un objet comme une abstraction, euh, comment dire..... Rien de plus concret, dans la machine, qu'un objet : c'est un agrégat de données qui suit la structure et les comportements qui ont été définis dans sa classe. Il peut en effet y en avoir plusieurs qui collent à la même classe, comme tu le dis.

---

Je n'ai jamais fais de la POO, d'où le titre de mon post. Mais à ma juste connaissance des concepts c'est tout à fait logique de partir de l'objet pour aller vers la classe. Je m'explique : tout d'abord, il faut comprendre que les concepts de classe et d'objet sont interdépendants. Une classe est l'abstraction d'un ensemble d'objets qui possèdent une structure identique (liste des attributs) et un même comportement (liste des opérations). Un objet est l'instance d'une et une seule classe. C'est pour dire que sans l'objet on ne peut pas encore parler de classe. Autrement dit on parlerait d'une classe abstraite (classe qui n'a pas d'instance) qui est un autre concept à part.

Par ailleurs, si j'ai parlé d'un objet comme étant une abstraction, je me situe déjà dans le système que je veux modéliser. Dans ce contexte, un objet représente une entité du monde réel (une personne, une ampoule) ou du monde virtuel pour les objets immatériels qui se caractérise par un ensemble de propriétés (des attributs, des états significatifs et un comportent). On ne pourra jamais représenter une personne par la personne
elle-même dans le système, mais par une représentation bien entendu abstraite de la personne. D'où la définition de l'objet comme étant une abstraction.

Citation:

---

Envoyé par soslab

(.../...)
Par ailleurs, si j'ai parlé d'un objet comme étant une abstraction,(.../...)

---

Dont acte. L'aspect abstrait/concret dépend en effet de là ou on pose son point de vue.

Mais fais gaffe, la programmation, orientée objet ou pas, est avant tout une question de pratique. La théorie, c'est bien(et j'adore ça), mais n'a de sens que quand on met les mains dans le "cambouis". N'hésite pas à faire des essais sur un langage objet quelconque, et à essayer un à un les éléments que Pyramidev a donnés. Ca devrait te prendre déjà pas mal de temps. Mais surtout, ça donnera corps à toutes ces idées, ça permettra de mieux les ressentir, de comprendre mieux ce qui se cache derrière.

D'ou la différence de point de vue entre toi et moi sur comment regarder l'objet : pour moi, c'est concret, parce-que j'en manipule, j'en regarde les entrailles dans le débogueur. Pour toi, c'est abstrait, parce-que c'est une représentation numérique d'un élément concret du monde réel. Ce qui est vrai aussi. Vrai, mais qui dénote une absence d'habitude de manipulation. Une compréhension purement théorique n'est pas d'une grande utilité(même si elle est très rigolote).

Citation:

---

Envoyé par soslab

Bonjour Marco46,

Pour faire simple, un objet est une abstraction ou une chose qui a un sens dans le contexte du système à modéliser. Chaque objet a une identité et peut être distingué des autres sans considerer à priori les valeurs de ses propriétés.

Un classe décrit un groupe d'objets ayant les mêmes propriétés (attributs), un même comportement (opération) et une sémantique commune (domaine de définition).

Satisfait ?

---

Où as-tu trouvé cela ? Est-ce que tu comprends ce que tu écris ?

Citation:

---

Envoyé par el_slapper

(...)
Moi, ma définition de la POO, c'est que c'est juste une autre manière de stocker le code : au lieu de mettre d'un coté les structures de données et de l'autre le code qui va agir sur les données contenues dans ces structures(comme en procédural), on va mettre le code qui agit sur lesdites données dans la structure elle-même. Ce qui change complètement la manière de penser. Il y a des milliards de définitions différentes, mais celle-ci est celle qui me convient. Les autres sont justes aussi, hein, et plus tu en liras de différentes, plus tu pigeras la différence.

---

Pas mieux.

On note que c'est une définition claire et utile pour quiconque a vraiment l'intention d'apprendre à programmer, mais forcément toujours trop obscure pour un touriste... pour un touriste aucune définition de quelque chose de complexe ne sera jamais assez simple :D

Citation:

---

Envoyé par Jamatronic

Où as-tu trouvé cela ? Est-ce que tu comprends ce que tu écris ?

---

Sinon je ne l'aurai pas posté.