Besoin d'éclaircissements sur la POO

Bonjour tout le monde

Je me permets de revenir vers vous, car j’aurais vraiment besoin d’éclaircissements sur la façon d’assimiler la POO.

J’ai appris certaines notions, et en cherchant des informations précises sur des forums, notamment celui-ci mais pas que :), je me suis rendu compte que la POO était à priori souvent mal enseignée. Et j’ai tendance à croire les personnes qui disent cela puisque ceux sont généralement des gens dont l’expérience n’est plus à prouver.

Mais alors le problème c’est que du coup ça me perd complètement et me fait revenir sur pas mal de choses que j’apprends depuis deux ans.

Par exemple, j’ai vu revenir souvent cette notion :

• C’est une très mauvais habitude que d’apprendre le fait qu’un Chat est un Animal spécialisé. Ah bon ? Mais pourquoi ? Je pensais que c’était le principe de l’héritage. On créé une classe Animal, qui contient un certains nombres d’attributs et de méthodes, et on crée une classe Chat qui hérite de Animal mais avec des choses en plus. Qu’est-ce qui ne va pas dans ce raisonnement du coup ?

Exemple trouvé : Sur ce forum

• Il est souvent expliqué que l’ECS (Entity Component System) est une meilleure approche, mais qu’en même temps ça ne remplace pas la POO.. Enfin je ne comprends pas grand chose.

J’ai lu plusieurs sujets semblables à celui-ci : Lien vers forum OC

J’aimerais vraiment un éclaircissement car c’est un sujet qui m’intéresse beaucoup et je voudrais bien prendre les bonnes habitudes dès le départ.

Merci à tous pour la patience dont vous saurez faire preuve

Pour l’ECS, je laisse les experts concernés continuer à en discuter s’ils le veulent.

Pourquoi ne peut-on pas dire que le chat est un animal spécialisé?

Cela supposerait que certains attributs des chats sont différents de ceux des autres animaux. Si tu me dis que le chat ne respirent pas de l’oxygène, je serais forcé de te dire que le chat n’est pas un animal. Le chat est un animal. Il possède donc tous les attributs des animaux, mais il possède en plus d’autres attributs particuliers.

Il faut donc déterminer les attributs communs à tous les animaux et ajouter les attributs particuliers à chaque animal.

Par exemple, le chat miaule et le chien jappe.

Merci pour ton retour

Du coup, justement dans ce que tu viens d’expliquer je ne pige pas où était l’erreur initiale. Ou alors, je n’ai pas peut être pas compris ce qu’on met derrière la notion de spécialisée.

Dans ton exemple, le chat respire de l’oxygène, nous sommes d’accord. Et comme c’est un attribut vraisemblablement commun à tous les animaux, celui-là est placé dans la classe Animal. Donc en créant le chat, celui-ci en héritera.

Ensuite tu dis, cela supposerait que certains des attributs des chats sont différents de ceux des autres animaux. Bah c’est le cas non ? En plus, tu le dis bien juste après :

Il faut donc déterminer les attributs communs à tous les animaux et ajouter les attributs particuliers à chaque animal.

Par exemple, le chat miaule et le chien jappe.

Donc le chat a bien certains de ses attributs différents des autres animaux ?

Puisque le chat miaule, il a bien un attribut que le chien n’aura pas.

Le problème initial c’est d’illustrer les concepts de POO avec des notions du monde réel, qui donne quelque chose de très abstrait : à quel moment a-t-on besoin de représenter un objet Chat dans un programme ?

Et si ça devait l’être, pourquoi est-ce que ça devrait reposer sur de l’héritage ? Ça ne paraît pas très pertinent puisqu’un chat n’étend pas le concept d’animal (on ne lui ajoute pas de comportements, qu’il partage avec d’autres animaux) mais possède certains attributs qui varient par rapport à d’autres (son cri est le miaulement).

Le problème initial c’est d’illustrer les concepts de POO avec des notions du monde réel, qui donne quelque chose de très abstrait : à quel moment a-t-on besoin de représenter un objet Chat dans un programme ?

Oui c’est pas faux. J’ai repris cet exemple parce que c’était dans un post qui m’avait interpellé.

Et si ça devait l’être, pourquoi est-ce que ça devrait reposer sur de l’héritage ? Ça ne paraît pas très pertinent puisqu’un chat n’étend pas le concept d’animal

Justement, c’est ce qui m’a amené à venir demander conseil. J’ai l’impression de ne pas avoir appris la POO de la bonne façon. Je garde l’exemple du chat puisqu’on est partit là dessus, mais je plussoie que ce n’est pas forcément un bon exemple.

Pour moi, l’héritage était utile justement puisque le chat hérite des attributs de la classe Animal et a ensuite de nouveaux attributs par rapport à d’autres animaux. L’exemple du miaulement n’est pas parlant puisqu’effectivement il s’agit du même attribut cri. Mais par exemple, dans la classe Animal, j’y placerai un attribut EstVivant et le chat en hérite du coup.

J’étais parti pour écrire un truc, mais ça s’est transformé en pavé qui va partir dans un billet.

Surveille la page d’accueil !

J’étais parti pour écrire un truc, mais ça s’est transformé en pavé qui va partir dans un billet.

Surveille la page d’accueil !

ça marche, merci Je reste aux aguets !

Ce que tu racontes me fait penser aux formes géométriques :

Un carré est un rectangle et un losange qui sont tous des quadrilatères. Si tu essaies de modéliser ça par des classes et de l’héritage, tu vas être un peu coincé ! Classiquement, on va penser faire une classe pour chaque, mais premièrement carré hérite de rectangle et losange, l’héritage multiple pouvant déjà être un problème en soi, mais ensuite carré n’ajoute aucune propriété, alors que se passe-t-il ?

Un rectangle peut être défini par sa largeur et sa longueur, des propriétés qui vont être égales dans un carré…

Quand je lis les questions qui parlent d’attributs, c’est signe que l’on a les mauvais réflexes. Ce qui fait vraiment la différence de l’OO ce n’est pas la donnée possédée (point de départ de nombreuses ressources que je range très facilement dans "mauvaises ressources"), mais le comportement. Un des cœurs de l’OO n’est pas la factorisation des données, mais la factorisation des comportements. (L’autre cœur important pour moi, c’est le couple abstraction/encapsulation).

Ce qui compte c’est ce que fait et peut faire ton animal. Si tous les animaux dont tu dérives disposent de tous les mêmes comportements parents (mais certes spécialisés), alors tu tiens ton héritage. Tant que l’on dit qu’un animal se déplace… OK. Si on commence à rentrer dans les détails… le manchot qui nage, le pingouin qui vole et qui nageouille, le chat sur son roomba domestique, le pigeon qui saute de marche en marche et préfère trotter… c’est l’enfer (EDIT: alors? Comment se déplacent les oiseaux? Les mammifères (quid du dauphin, de la chauve-souris)? Les reptiles?…). Du coup on va préférer coller des possibilités, des traits aux animaux, et mêmes aux entités vivantes que l’on va vouloir modéliser. C’est plus souple et flexible, cela aboutit avec les ECS, et cela n’a pas grand chose à voir avec de la conception/modélisation OO.

Pour le carré et le rectangle, sans même rajouter le losange, on a un problème de substituabilité: un carré modifiable n’est pas substituable à un rectangle modifiable. Cela rejoint le LSP (Principe de Substitution de Liskov) qui a déjà été débattu en long en large et en travers déjà.

Bref, je t’invite à consulter le big tuto C++ présent ici-même dans sa version bêta, ou dans son adaptation en livre, si tu veux une meilleure approche pédagogique — même si elle ne te dira pas où elle se distingue des autres et pourquoi elle est plus juste.

EDIT-PS: Je viens de relire plus attentivement un message, à propos de "l’attribut respirer de l’oxygène". Je n’aime pas le terme attribut ici, car "attribut" a un sens fort de "donnée" dans la terminologie OO courante. Je préfère utiliser le terme "trait": un des traits de moult animaux est de pouvoir respirer de l’oxygène. Et pour le coup ce trait est parfait pour contredire la modélisation OO du règne animal: il existerait un parasite de la famille des méduses qui ne consomme pas d’oxgène. Il y a tellement de contre-exemples aux généralités dans le règne animal, qu’une modélisation entièrement OO avec des héritages dans tous les sens devient vite impossible.

@Imghs merci pour le temps accordé à me répondre

EDIT-PS: Je viens de relire plus attentivement un message, à propos de "l’attribut respirer de l’oxygène". Je n’aime pas le terme attribut ici, car "attribut" a un sens fort de "donnée" dans la terminologie OO courante. Je préfère utiliser le terme "trait": un des traits de moult animaux est de pouvoir respirer de l’oxygène. Et pour le coup ce trait est parfait pour contredire la modélisation OO du règne animal: il existerait un [parasite de la famille des méduses qui ne consomme pas d’oxygène

D’accord, mais du coup ce serait quoi la solution ? Il faudrait créer une classe Respirer et y décrire toutes les possiblités, toutes les façons de respirer possibles, dont a besoin ? Et dans ma classe Chat, n’attribuer que le type de respiration qui convient ?

J’ai un peu de mal avec tout ça, mais j’imagine que ça vient avec le temps.

J’ai hâte de voir ce que @Spacefox en dit, mais je me permet tout de même de donner mon petit grain de sel (d’autant que je suis l’auteur d’un des sujet cité).

Pour moi, le paradigme OO (ou Entity Component System, ou fonctionnel, ou …) à certes des implications "pratiques" (écrire les classes, gérer l’héritage, etc), mais induit aussi une façon de penser ton code et la façon dont vont s’articuler les données à l’intérieur de celui-ci (parce qu’en pratique, la notion d’objet, ça n’existe pas au niveau du processeur, même si t’as souvent une garantie que les données correspondantes vont se trouver à peu près au même endroit en mémoire). Adopter le paradigme OO, c’est avant tout penser ton programme sous forme d’objets qui interagissent entre eux, en suivant plus ou moins les principes SOLID.

Par ailleurs, pour moi, Entity Component System répond avant tout à une contrainte d’organisation des données en mémoire (et de performance) avant d’être un paradigme qui serait "mieux" ou "moins bien" que la POO

Il n’y a pas "une" solution. Il y en a plusieurs. Cependant on peut dire que d’avoir une hiérarchie complexe d’héritages qui vont apporter des traits ou d’autres ne sera pas la solution. Et ce coté typique de l’OO, n’est pas une solution. En tout cas, certainement pas dans l’exagération.

En revanche composer des traits sera une bien meilleure approche, AMA. Surtout quand on essaie de modéliser des systèmes complexes comme le vivant où il y a des exceptions aux exceptions…

Un comment, par composition et design pattern strategy p.ex. Un autre par ECS. D’autres? Probablement.

Par ailleurs, pour moi, Entity Component System répond avant tout à une contrainte d’organisation des données en mémoire (et de performance) avant d’être un paradigme qui serait "mieux" ou "moins bien" que la POO

Les premières lignes sur wikipédia vont plus dans le sens du design que de l’organisation des données en RAM. C’est encore plus "clair" sur http://entity-systems.wikidot.com/

Le fait que le chat miaule alors que le chien ne miaule pas, ça me paraît un très mauvais argument.

Dans la classe 'Animal’, je vais normalement définir un attribut qui est 'type de cri’, et la valeur que j’aurai pour le chat, c’est 'Miaulement' et pour le chien 'Aboiement’. L’attribut 'type de cri' a sa place à part entière dans la classe 'Animal’.

Il y a intérêt à créer une classe 'Chat' uniquement si il y a certaines caractéristiques propres au chat. (je dis bien caractéristiques, pas valeurs de caractéristiques).

Or, je ne vois aucune caractéristique qui justifie la création d’une sous-classe chat.

Donc oui, prendre comme exemple la classe chat qui hérite de la classe animal, ça me paraît une erreur pédagogique.

Si on veut rester dans le domaine animal, on peut avoir une classe 'animal’, et des sous-classes 'mammifères terrestres’, 'poissons’ ; ok, c’est justifié.

Je préfère une classe meuble (avec par exemple des caractéristiques 'matériau’, 'prix' , 'date-d-achat’, 'longueur’, 'largeur’, 'hauteur’) puis une sous classe 'table’, une sous-classe 'meuble de rangement’, une sous-classe 'meuble pour s’asseoir’, etc

Là, on a clairement des caractéristiques communes (les premières citées), et des caractéristiques spécifiques à chaque sous-classe. Par exemple, 'nombre de places assises’, c’est un attribut spécifique à la classe 'Meubles pour s’asseoir’.

Or, je ne vois aucune caractéristique qui justifie la création d’une sous-classe chat.

En gros, si j’ai bien compris : on crée une nouvelle classe "descendante" uniquement si cette dernière se justifie par de nouvelles caractéristiques ou de nouveaux comportements. Autrement dit, dans notre cas, le Chat n’a pas d’utilité puisque c’est un Animal dont on peut juste changer la valeur du cri, la valeur du nom, etc. Donc créer notre Chat en faisant une instance de la classe Animal ça suffit du coup, c’est bien ça ?

Par contre, si c’est un oiseau, la on pourrait créer une nouvelle classe ? Dans la mesure où on a affaire à un animal volant ?

En OO, considérer que l’héritage ajoute des choses est une erreur. Ce qui est ajouté ne peut pas être pris en compte dans le LSP: on ne peut pas manipuler quelque chose qui n’est pas connu de la classe de base, ce qui rend cette approche caduque. En OO, on modifie des comportements et c’est tout.

Comme le dit lmghs, si on parle d’attribut ou de caractéristique, on a les mauvais réflexes: on veut en ajouter et on ne réfléchit pas au comportement de nos objets.

Dans le principe, on définit une classe et des services (ces fonctions) avec des pré-conditions et post-conditions. On ne peut pas restreindre les pré-conditions, on ne peut pas élargir les post-conditions et si on ajoute des comportements personne ne peut les utiliser sans briser LSP ou autres principe SOLID. Ça se veut carré et généralement ça passe.

L’ESC à contrario permet d’ajouter des données aux entités et non des comportements qui eux sont gérés par des systèmes. C’est un monde très dynamique où l’ajout de donnée influence les comportements et qui permet de changer la nature d’une entité à tout moment.

Si tu fais reference au message de Stranger, tu as mal compris ses propos. Il décrit ce qu’est un ECS. Il ne dit pas que c’est mauvais (ou bon d’ailleurs), juste comment cela peut être conçu dans un ECS (et donc en POO) :

• ECS : un chat est la composition de ANIMAL et de MOUSTACHES
• POO : un chat est un ANIMAL AVEC MOUSTACHES (qui hérite de ANIMAL)

(Et comme l’a dit lmghs, on modélise des comportements, pas des attributs, donc ça aurait été mieux un exemple avec "pousser un cri" par exemple).

Un point important dans le message de Stranger, c’est qu’il n’y a pas de jugement de valeurs sur les approches. Il n’y a pas de bonnes ou mauvaises approches. Comme le sous entend aussi lmghs, c’est des solutions qui répondent a des contextes spécifiques, pas des solutions universelles (même si c’est parfois enseigné comme ça, pour des raisons pédagogiques).

Un exemple concret, on dit souvent que copier-coller le code est une mauvaise chose. Copier-coller 1000 lignes de code, que l’on modifie toutes les semaines, c’est un problème. Par contre, si tu copies-colles 2 lignes de code et que tu les modifie tous les 10 ans, c’est osef.

Tout cela pour dire qu’a un certain point, on ne peut plus réfléchir sur les architectures logicielles dans l’absolu. Il faut adapter en fonction des projets concrets sur lesquels on bosse, en fonction des avantages et défauts sur ces projets spécifiquement.

Par contre, si c’est un oiseau, la on pourrait créer une nouvelle classe ? Dans la mesure où on a affaire à un animal volant ?

Le comportement "voler" est un bon exemple de cette question de design dans des projets concrets.

Imagine que tu fais un programme qui doit modéliser des chiens, chats, poissons et oiseaux uniquement. Dans ce cas, avoir une classe "oiseau", qui hérite de "animal" et ajoute ce comportement "voler", ça peut avoir du sens.

class animal {
public:
    void respirer();
    void manger();
};

class chien : public animal {};

class chat : public animal {};

class poisson : public animal {
public:
    void nager();
};
    
class oiseau : public animal {
public:
    void voler();
};

Ce design répond a cette problématique.

Dans un autre programme, tu dois modéliser aussi les insectes (qui peuvent voler).

class insecte : public animal {
public:
    void voler();
};

Ca veut dire que :

1. le code de voler est dupliqué. Si tu modifie l’un, tu devras probablement modifier l’autre.
2. si tu as 100 classes qui doivent voler, ca va devenir compliqué
3. si tu veux un tableau des animaux qui peuvent voler, tu devras avoir par exemple un vector<animal*> et faire un test pour savoir si c’est un animal qui vole ou pas.

On voit dans ce cas que le premier design pose des problèmes et n’est pas adapté au second problème.

Est-ce que cela veut dire que le premier design est incorrect ? Non. Juste qu’il n’est pas adapté dans tous les cas.

Sauf que… qui te dit que ton premier programme ne va pas évoluer dans 1 an et que tu devras ajouter une classe insecte ? Quelle est la bonne solution dans ce cas, prévoir que ton programme peut évoluer et faire tout de suite le second design (et donc faire un travail supplémentaire qui n’est pas utile pour le moment - voire ne sera jamais utile) ou accepter de changer le design au cours du temps si les besoins changent ?

Il n’y a pas de réponse toute faite et donc pas de design qui serait meilleur qu’un autre. Juste des choix en fonction des contraintes actuelles et estimées. Ce qui relève pas mal des arts divinatoires.

Comment résoudre ce second design. On va simplement identifier les comportements qu’on peut factoriser et les mettre dans des classes. Par exemple :

class animal_volant : public animal {
public:
    void voler();
};

class oiseau : public animal_volant {};

class oiseau : public animal_volant {};

Ce travail d’identification des comportements est important et pas forcément simple, parce que l’on modélise pas forcément des choses concrètes, mais souvent des abstractions. On ne crée pas "animal volant" parce que cela a du sens au niveau biologique, mais parce que cela répond a une problématique de design logiciel, dans cette problématique particulière.

On peut aller plus loin et ajouter une classe pour les animaux qui nagent.

class animal_nageant : public animal {
public:
    void nager();
};

class poisson : public animal_nageant {};

Et maintenant, on veut un poisson volant…

class poisson : public animal_nageant, public animal_volant {};

Ca commence a poser problème. Il faudra correctement implémenter l’héritage multiple et surtout on va se retrouver avec des designs parfois pires que le problème qu’on veut résoudre.

Arrive les ECS (et d’autres designs). L’idée est simplement de modéliser les comportements comme des classes a part entières, pas comme des ajouts a des classes existantes. Par exemple, on va faire :

class peut_respirer {
public:
    void respirer();
};

class peut_manger {
public:
    void manger();
};

class peut_voler {
public:
    void voler();
};

class peut_nager {
public:
    void nager();
};

class animal : public peut_respirer, public peut_manger {};
class chien : public animal {};
class chat : public animal {};
class oiseau : public animal, public peut_voler {};
class poisson : public animal, public peut_nager {};
class poisson_volant : public animal, public peut_voler, public peut_nager {};

(Je montre dans cet exemple une composition des comportements par héritage, mais on peut aussi utiliser par exemple un attribut vector<comportement*> ou d’autres designs).

Dans tous les cas, l’idée est la même : ce ne sont que des solutions a des problèmes spécifiques, qui ont des avantages et défauts.

L’exemple du miaulement n’est pas parlant puisqu’effectivement il s’agit du même attribut cri.

Pas forcément, ca dépend du design. Dans mon exemple, pousser un cri n’est pas un comportement commun a tous les animaux (par exemple les poissons et les insectes, dans cet exemple - mais on pourrait imaginer d’autres exemples où les poissons et les insectes ont d’autres modes de communication).

En OO, considérer que l’héritage ajoute des choses est une erreur. Ce qui est ajouté ne peut pas être pris en compte dans le LSP: on ne peut pas manipuler quelque chose qui n’est pas connu de la classe de base, ce qui rend cette approche caduque. En OO, on modifie des comportements et c’est tout.

Ca me semble discutable.

Si on prend un cas classique : une GUI (Qt au hasard). Chaque sous-classe peut modifier le comportement d’une classe de base (par exemple la fonction draw, pour que chaque widget s’affiche différemment a l’écran), mais également ajouter des comportements (par exemple de pouvoir cliquer pour une classe button).

Du point de vu LSP, pour les classes qui vont manipuler la classe de base, il est vrai que ce nouveau comportement n’est pas connu et donc qu’essayer d’y accéder via la classe de base pose un problème en termes de POO.

Pour autant, cela ne veut pas dire que d’autres classes ne vont pas manipuler directement cette classe button et ses classes dérivées et donc que le LSP sera respecté du point de vue de ces classes qui manipulent des button.

Pour cela que LSP et ajout de comportements ne me semblent pas incompatibles. Ce qui poserait problème, c’est d’essayer d’accéder aux boutons via la classe de base.

@jo_link_noir : merci pour ta réponse. Au moment où j’étais en train de te répondre pour te demander si tu n’avais pas des exemples concrets pour illustrer pour aider à comprendre, gbdivers a publié au même moment

@gbdivers : un grand merci pour ces éclairssissements vraiment ! Et pour les exemples donnés aussi

Si tu fais reference au message de Stranger, tu as mal compris ses propos. Il décrit ce qu’est un ECS. Il ne dit pas que c’est mauvais (ou bas d’ailleurs), juste comment cela peut être conçu dans un ECS (et donc en POO) :

Non ce n’est pas nécéssairement au message de Stranger que je faisais référence, mais à l’ensemble du post. J’ai pris celui-ci car il était représentatif de ce que j’ai déjà vu sur d’autres forums ou dans d’autres sujets. En gros, l’idée que certains professeurs, formateurs, tutoriels, etc. enseignaient mal ces notions ou du moins qu’on se focalisait sur la notion d’héritage du type justement Animal -> Chat.

Finalement, si je comprends bien, tout ceci va dépendre du projet sur lequel on va travailler. Un petit ou gros projet, un projet qui évoluera ou non, à quelle fréquence, etc. L’ECS est donc une autre "approche" plus adaptée aux gros projets et qui facilite la maintenabilité ?

Arrive les ECS (et d’autres designs). L’idée est simplement de modéliser les comportements comme des classes a >part entières, pas comme des ajouts a des classes existantes. Par exemple, on va faire :

Dans l’exemple que tu donnes, on ne pourrait pas regrouper tous les comportements possibles dans une seule et même classe et les autoriser par un système de booléen ? PLutôt que de créer une classe pour chaque comportement ?

Non. Plutôt les projets où il y a pleins de comportements différents et pleins d’associations possibles de ce comportements. Ce qui rend très difficile d’avoir un héritage.

Egalement, le fait qu’un ECS rassemble des comportements identiques ensemble, cela facilite la cohésion de la mémoire, ce qui peut avoir un impact sur les performances.

Dans l’exemple que tu donnes, on ne pourrait pas regrouper tous les comportements possibles dans une seule et même classe et les autoriser par un système de booléen ? PLutôt que de créer une classe pour chaque comportement ?

Si. Si les comportements ne contiennent pas de données.

Quand on parle d’ECS, il faut bien comprendre que ce n’est pas un design et une implémentation unique, mais une famille d’approches.

Chose promise, chose due.

Bizarre, je l’ai lu en entier, j’étais en train de te poser des questions en commentaires, et le lien est down ?

peut-être en rapport avec la panne de ce matin ?

Du coup j’ai un peu la flemme de tout réécrire… Donc je vais résumer assez vite ce que je t’avais écris :

• Un grand merci pour tous ces éclairssissements qui effectivement permettent de mieux comprendre la POO et en opposition avec ce qui est généralement enseigné.

• Question : du coup, si j’ai bien compris, il est important de connapitre plusieurs paradigmes de programmations, mais justement pour un débutant c’est là toute la difficulté: Quel(s) paradigme(s) utiliser dans mon projet pour y répondre au mieux ? As-tu des ouvrages, tutoriels à conseiller pour s’entrainer là dessus ou est-ce vraiment quelque chose qui vient tout seul à force de programmer, de se planter et de recommencer ?

-Question sur Java: le conseilles-tu malgré tout aujourd’hui ? Ou s’investir dans ce langage est-il une perte de temps et mieux vaut se tourner vers un autre langage plus multi-paradigmes ?

Voilà grossièrement ce que j’avais écris