Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
La poo c'est quoi concrètement ?
Salut,
Tout à l'heure j'étais sur un topic, et en voyant que ça parler de Prog Orienté Objet, je me suis pour la enième fois demandé ce qu'était la POO concrètement.
Et accessoirement, qu'est ce que ça implique la POO ? Càd, quand tu codes dans un langage orienté objet, tu as quoi en tête par rapport à un autre langage ? Quels sont les habitudes/possibilités propres à la POO ?
Merci d'avance pour vos réponses.
La POO, c'est le seul moyen qu'on à pu trouver pour lutter contre l'invasion des spaghettis
Ah ben merci c'est tout de suite plus clair xDEnvoyé par psychadelic
Non, ça c'est la programmation structurée. Dans les années 1970, l'Université de Waterloo, en Ontario, a développé des versions structurées du Fortran. À l'époque, Fortran n'avait rien d'un langage objet. Aujourd'hui ? Je ne sais pas.
Ceux qui ont bourlingué dans l'univers du code, surtout en TMA, c'est parlant : on a trop souvent été confrontés à des programmations monstrueuses, écrite et réécrites des douzaines de fois par des codeurs différents, pour y ajouter de nouvelles "features" mais sans jamais avoir suffisamment de temps et de budget pour les implémenter proprement, avec dans le meilleur des cas une documentation sommaire.
Bref, quand tu rentre dans ce type de code, tu commence par un bout que tu tire petit à petit, en croisant d'autre bouts que tu traces aussi,en essayant de défaire les nœuds, mais au bout d'un moment tu t’aperçois que tu es au milieu d'un plat de spaghettis.
En POO, c'est moins courant, et puis tu peux faire des tests unitaires sur chaque objet, ce qui facilite énormément le debugging.
Concrètement, il s'agit de programmer en utilisant l'encapsulation et l'héritage.
L'encapsulation, c'est quand les variables membres d'une classes ne sont directement accessibles que par un ensemble fixe et prédéfini de fonctions rattachées à la classe, qui sont alors appelées les méthodes de la classe. En C++ et en Java, l'encapsulation se fait principalement avec le mot-clef private.
L'héritage, c'est une fonctionnalité parmi d'autres qui permet de faire du polymorphisme, c'est-à-dire d'écrire un code qui sera utilisable pour plusieurs types à la fois. Comme je sais que tu étudies le C++, je te laisse découvrir l'héritage en C++.
Remarque 1 : pour qu'un langage soit considéré comme purement objet, à part supporter ces deux fonctionnalités, il y a encore d'autres contraintes. Plus d'infos : Why is Java not a pure OOP Language?
Remarque 2 : l'encapsulation n'est pas un concept exclusif à la POO. Par contre, l'héritage, si.
Merci pyramidev, c'est beaucoup plus clair comme ça
*musique illuminati* xD
Edit: Et le lien explique bien merci ^^. Maintenant je comprendraisJe passe en résolu
la POO n'évite pas ça. Ce qu'elle évite(et c'est déjà pas mal), ce sont les redites. Il est plus facile d'éviter de faire de bêtes copier-coller-adapter en objet, pour tout un tas de raisons. J'ai eu à refondre une chaine batch COBOL, et j'ai trouvé plus de 40 fois le même code(qui disait en gros que si l'adresse était en Alsace Moselle, on utilisait un autre prestataire pour envoyer le courrier). Ca, en objet, je n'en ai jamais entendu parler, et c'est une force massive de cette doctrine. Mais du code spaghetti avec plein d'encapsulations incompréhensibles tellement il y a de niveaux d'appel? ben j'en ai vu en objet aussi, et plein de gens aussi.
Tu peux faire des tests unitaires sur chaque composant en procédural, si tu te donnes la peine. Ce n'est hélas pas la culture, mais je l'ai fait à plein de reprises. Ca marche, et ça facilite, en effet, le débugging. Mais ça n'a rien de spécifique
en VBA aussi(langage des années 80/90, je rappelle). Y compris quand on ne fait pas de classes. L'encapsulation n'est aucunement un concept objet. Qu'on enseigne l'encapsulation aux gens qui font de la POO est une bonne chose, mais les deux ne sont pas liés.
C'est en effet un poil plus compliqué de faire du polymorphisme en procédural. On est obligé de coder l'appel à la fonction centrale(qui correspond à la mère de l'héritage) depuis les fonctions spécifiques à chaque type(qui correspondent aux classes filles), ce qui doit faire une, voire deux lignes de code en plus. La mort.
Rigolote, la liste. Reprenons là :
Evidemment, en procédural, comme on a pas(ou pas uniquement) d'objets, les points 5, 6, et 7 ne s'appliquent pas. Mais c'est juste une question de définition, si on ne fait pas de l'objet, on n'en fait pas, par définition. Ca n'est pas ça qui va te dire ce qu'apporte la POO(1)Encapsulation/Data Hiding
(2)Inheritance
(3)Polymorphism
(3)Abstraction
(5)All predefined types are objects
(6)All operations are performed by sending messages to objects
(7)All user defined types are objects.
Le point 1, par contre, se gère totalement, je l'ai montré plus haut. Le point 3 aussi, même si c'est syntaxiquement plus compliqué. Le point 4, ben, on fait une procédure coquille qui englobe la vraie viande, ça se conçoit assez différemment de l'objet, c'est plus compliqué, mais ça se fait.
La seule vraie différence, c'est le point 2. L'héritage. Qui n'a aucun sens en procédural puisqu'une structure de données ne se balade jamais avec le code associé, en procédural. C'est le point qui explique pourquoi les redites de code sont beaucoup plus rares en objet(encore une fois, un avantage majeur à mes yeux).
Et c'est le seul - avec le concept qui va avec, celui de classe(doublon structure-code). Avec des conséquences gigantesques, hein, ne me faites pas dire ce que je n'ai pas dit. Une architecture POO n'a rien à voir avec une architecture procédurale. Il faut penser complètement autrement en objet. Mais ceci est la seule et unique raison.
Mais, et j'insiste, en procédural, on peut faire de l'encapsulation, du test automatique, du polymorphisme, voire même de l'abstraction(certes sous une forme différente). On peut faire du code propre, réutilisable. Il faut plus de discipline et d'auto-discipline pour éviter la duplication de code, certes. Mais je refuse cette propagande du "le procédural c'est caca on peut rien faire de propre". C'est faux.
C'est un peu ce que je demandais lorsque je demandais ce que la POO impliquer. Et ça je l'ai pas tout à fait compris. En fait dans un code en Python, je n'utilise quasiment jamais de classes. Du coup je fais pas de POO ? Et si je voulais utiliser des classes, quel choses différentes devrait je garder en tête par exemple ? Je prend l'exemple de python car c'est le langage que je connais le mieux.
Il est magnifique, ce lien. Sur la même page, dans la section "related questions", il y a ceci:
Is java a pure oop language or not?
Yes, it is pure OOP. READ MORE
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Le procédural rend difficile les tests unitaires sur des algorithmes dont une partie des opérations interagissent avec l'extérieur du programme (ex : lecture et écriture en base de données, envoi de courriel, etc.) ou ne sont pas déterministes (typiquement celles qui font intervenir de l'aléatoire).
Dans n'importe quel paradigme de plus haut niveau que le procédural, pour faire des tests unitaires sur un tel algo, on crée des abstractions par dessus toutes les impuretés. Dans le cas de la POO, on appelle cela des mocks. Par exemple, pour l'envoi de courriel, il y aura une classe de base avec au moins deux classes dérivées : une qui enverra vraiment le courriel (celle qui sera utilisée en prod) et une qui n'enverra rien et se contentera de se rappeler à qui elle est supposé avoir envoyé un courriel (celle qui sera utilisée pour les tests unitaires).
En vrai procédural, on est obligé de coupler l'algo général avec chaque possibilité d'implémentation. On passe alors de paramètre en paramètre des booléens ou des énumérations pour savoir quelle implémentation il faut exécuter. On passe souvent aussi des paramètres qui ne servent que pour certaines implémentations, mais pas d'autres. Et c'est dans ce genre de cas qu'il est effectivement légitime de dire que "le procédural c'est caca on peut rien faire de propre".
Cela dit, pour les tests unitaires, le paradigme le plus fort est le paradigme fonctionnel. Mais c'est un autre sujet.
J'avais remarqué mais bon xD, en creusant un peu sur internet, ce lien expliquait la même chose que la plupart des autres site.
Il n'y a pas de consensus fort sur ce qu'est exactement l'OO. Mais il y a malgré tout un ensemble minimum de fonctionnalités qui est présent dans la quasi-totalité de la littérature sur le sujet :
- Une forme d'encapsulation
- Une forme de sous-typage (l'héritage pour le C++) quelle soit nominale ou structurelle
- Le polymorphisme de sous-typage qui vient avec
- Une forme de single dispatch, c'est à dire d'appeler la fonction membre correspondant au type effectif de l'objet auquel elle appartient et non celle du type déclaré (c'est le virtual en C++).
Les trois premiers points sont ceux décrit par Pyramidev, le dernier n'est pas explicitement mentionné mais il était très probablement implicite (le gros de l'intérêt du sous-typage est perdu sans ça).
Où il n'y pas de consensus fort, c'est que la plupart des auteurs sur le sujet embarquent d'autres fonctionnalités dans leur vision de l'OO mais sans qu'elles fassent l'unanimité : un mécanisme d'exception, un support natif des contrats, du multi-dispatch, etc. (si tu prends B. Meyer, la liste est telle qu'hors d'Eiffel, il n'y a pas d'OO).
Et ça se complique encore quand on parle de langage car pour certains un langage est objet dès qu'il propose ces mécanismes alors que d'autres ne le considèrent comme tel que s'il les imposent, y compris dans le langage lui-même et dans la bibliothèque standard (donc sur les types primitifs). Certains parlant de langage pur objet pour ce dernier cas.
Après ce point n'est pas propre à l'OO, cette distinction entre mécanisme proposé ou imposé pour qualifier un langage se retrouve pour tous les paradigmes.
Plutôt que de passer plusieurs paramètres et de faire transpirer les problématiques de test dans le code à tester, il est aussi possible de jouer avec l'édition de lien voire le chargement de bibliothèque partagée. Typiquement dans l'exemple d'envoi de mail, tu as d'un côté ta bibliothèque d'envoi et de l'autre une bibliothèque de test qui implémente la même API (et ABI) et tu charges celle-ci lors des tests. Ça fonctionne bien et, si le projet est correctement découpé (s'il ne l'est pas, l'utilisation de l'OO par la même équipe n'aurait très certainement pas donné un découpage en classe cohérent) c'est simple à mettre en place. C'est une forme de mock hors du mode objet.
Je ne sais pas si on peut toujours appeler ça du procédural mais, effectivement, ça marche dans mon exemple de l'envoi de courriel. De manière générale, ça fonctionne bien dans le cas où, pour chaque code qui aurait utilisé une classe de base en POO, la classe dérivée utilisée serait à chaque fois la même pendant toute l'exécution du programme (mais différente d'un programme à l'autre).
Tout à fait.
Pour que les spaghetti ne s'entortillent pas, on a imaginé ( encapsulation ) de les cuire dans leur boite. Après on a imaginé la casserole spéciale qui peut contenir la boite. Après on a enseigné aux pâtes comment se faire cuire elles mêmes, et se faire manger ( méthodes ).
Etc. etc.
Merci Nebulix
J’ai l’impression que la vraie question ici n’est pas de connaître les principes de la POO, mais plutôt d’accepter la POO.
c’est vrai, la programmation c’est loin d’être «*naturel*». au travers cet apprentissage on découvre surtout des contraintes*: tout un tas d’instructions à apprendre pour faire «*juste un truc simple*» mais qui posent des problématiques qu’on ignorait avant*: le typage de variable, les effets de bords…
Bref après avoir passé un bon moment à savoir mettre en place une sorte de puzzle d’engrenages en perpétuels mouvement, «*on*» nous dit*: maintenant mon coco faut faire de la programmation objet, parce que tout ce que tu a fait jusqu’à présent c’est loin d’être «*pro*».
L’orgueil en prends un coup.
Perso j’aurais bien aimé voir la tête d’Ichbiah (Jean) quand il à finalement réalisé que seuls les langages objets avaient un avenir et qu’il devait laisser son bébé (le langage ADA) dans les mains de S. Tucker Taft.
Donc, pour comprendre la raison d’être de la POO, faut faire un peu d’histoire.
Ça part d’un principe simple*: la réutilisation du code. Très vite quand on code, on se retrouve à recoder sans cesse la même chose, comme par exemple un système de tableau de bord permettant de regrouper un ensemble d’information utiles. D’une appli a une autre les données sont rarement dans le même format, avec la même appellation, mais au final ça consiste toujours à collecter de l’info et à en faire la présentation, avec des recettes de cuisine au milieu, et le truc important c’est que la séquence d’instruction est sensiblement la même. Et à la longue ça devient pénible et lassant de coder les différentes variantes.
Bref, au bout d’un moment chaque codeur finit par avoir une sorte de «*boite à outil*» avec du code spécifique, et qu’il réutilise selon les besoins, avec les modifications utiles.
Le problème avec ce genre de boite à outil, c’est qu’elle n’a aucune cohérence, et comme certains nouveaux outils ajouté sont dérivés d’outils précédents, ils partagent les mêmes variables qu’on à pas forcement pris soin d’encapsuler proprement, ou que la langage ne permet pas du tout d’encapsuler (comme en COBOL, avant).
Il y a aussi le problème de la duplication du code*(2 ou plusieurs «*outils*» doivent coexister ensemble...
Bref le jour ou on se retrouve à dupliquer son propre code, mais en changeant le nom de toutes ses variables pour leur ajouter un trigramme pour les différencier (ou pire leur ajouter un chiffre), on commence à ce dire qu’il y certainement plus intelligent à faire.
Faut aussi comprendre que la POO colle bien avec les principes d’interface, et ce n’est pas un hasard si Alan Key s’en est inspiré pour Smaltalk*: Dans un interface graphique on à des tas de «*fenêtres*» à gérer, et ça colle complètement avec le principe d’instanciation des objets, une gestion commune de propriétés (ex: la case à cocher pour fermer la fenêtre) et ainsi de suite.
D’ailleurs quand on y regarde bien, on s’aperçoit que toutes les gestions d’interfaces sont faites en POO, idem pour les frameworks, etc.
Alors oui, le procédural c’est bien pour les «*petits*» trucs, mais ça tiens mal la route quand ils grossissent.
Bon bah votre débat, les différentes explications (merci gl,pyramidev et el slapper), m'ont éclairé. C'est pas encore totalement clair dans ma tête, mais je commence à comprendre ^^. Ca va venir à force x).
PS : Copié des fonctions changeant le nom des variables ça m'arrive déjà assez souvent merde(Et oui je rajoute un 2 derrière absolument).
A propos de réutilisation du code, j'ai un souvenir cuisant.
Il y a une trentaine d'années, Borland avait sorti un Turbo Pascal Objet et proposé un générateur d'interface objet : Turbo Vision, un peu lourd mais qui permettait de faire des IHM efficaces en mode alphanumérique, fondé sur des objets.
Puis le même éditeur a sorti Delphi pour fonctionner sous Windows, fondé sur des objets, mais pas les mêmes.
Réutilisation possible : ZERO.
Et pourtant. Depuis le début de l'humanité chaque génération enseigne à la suivante le "programme" pour bien cuire le mammouth.
Bienvenue au club (mais c'est plein à craquer)!
Des exemples dans le genre il y en a pas mal, et certains peuvent coûter très cher.
exemple: ceux qui ont codé toute une appli métier en Java-Microsoft et qui ont du abandonner 15années/hommes, du jour au lendemain, quand Microsoft à perdu son procès face à SUN (j'ai les noms).
plus récement on à aussi le passage de Angular version 1 à Angular version 2,... pas glop pas glop...
Répondre avec citation
Partager