Partage
  • Partager sur Facebook
  • Partager sur Twitter

Bénéfices concrets de la POO ??

    27 juin 2007 à 15:38:44

    Bonjour !
    Voilà j'ai quasiment fini de lire le cours sur le C++, j'ai trouvé particulierement intéressant l'exemple du RPG ( exemple développé dans les 2 leçons sur les classes ).
    En y réfléchissant, cet exemple on aurait pu le coder en C tout simple non ?

    par exemple on définit une structure, qui contient les différent attributes ( vie, mana, arme , dégâts), on déclare 2 variables de cette structure qui seront les 2 personnages
    quand aux fonctions du main.cpp :
    _ par exemple pour la fontion attaquer, elle prendrait en entrée 2 pointeurs vers les structures :

    void attaquer (personnage *perso1,personnage *perso2)
    {
    perso2->vie -= perso1->dégâts;
    }


    pour les autres méthodes, les fonctions ne serait pas non plus très compliquées à rédiger

    Voilà ma question, dans cet exemple du RPG, quels sont les bénéfices concrets de la POO ? a part la syntaxe plus "élégante" ?
    ( à défaut, vous pourriez me montrer un exemple ou les objets sont indispensables/programmer en C classique serait une horreur ? )

    Je début tout juste en POO, mais pour l'instant les objets je trouve que ca ne fait qu'inverser l'ordre dans lequel on écrit les fonctions/variables, un joli david.attaquer(goliath) plutôt qu'un attaquer(david, goliath) ??
    Ya aussi l'histoire des encapsulations, mais je vois pas trop trop l'utilité ( dans cet exemple en tout cas )

    merci
    • Partager sur Facebook
    • Partager sur Twitter
    Anonyme
      27 juin 2007 à 16:11:05

      Mais là , le cours sur la POO est incomplet .
      Il manque l'héritage , le polymorphisme ...
      • Partager sur Facebook
      • Partager sur Twitter
        27 juin 2007 à 16:16:27

        C'est vrai que quand on débute, on voit pas tout de suite l'intérêt de la POO, surtout qu'un seul des concepts de la POO (encapsulation) été présenté jusque là. Les avantages de la POO apparaissent surtout avec les notions d'héritage de polymorphisme et de template.

        Le principe de l'encapsulation est de regrouper ensemble les données (variables,...) et les traitements qui vont avec (fonctions,méthodes,opérateurs,...).

        Pourquoi faire une fonction qui prend en argument 2 personnages, alors que la notion d'attaque est intimement liee à ces personnages. Il n'y a que un personnage qui puisse attaquer, donc on associe cette "action" aux personnages en mettant ça dans une classe.

        Et puis il y a aussi le fait que pas tout le monde ne doit avoir accès aux points de vie d'un personnage. Tu n'as pas à avoir accès à la somme d'argent qui est sur mon compte banquaire, ce qui serait le cas si tu le faisais via une structure. ALors qu'en mettant mon compte banquaire en "private" tu n'y as accès que si tu me le demandes, i.e. via une méthode. Ca me permet de laisser les gens externes avoir accès qu'à ce que je veux qu'ils sachent.

        La programmation orientée objet n'est jamais obligatoire. On peut toujours faire sans. C'est juste une autre manière de voir les choses. Mais il est vrai que pour des grands projets, la POO simplifie le code puisque toutes les choses allant ensemble sont regroupées dans une même structure (pas au sens C++), la classe.


        • Partager sur Facebook
        • Partager sur Twitter
        Co-auteur du cours de C++. ||| Posez vos questions sur le forum ||| Me contacter.
          27 juin 2007 à 16:33:16

          Citation

          Pourquoi faire une fonction qui prend en argument 2 personnages, alors que la notion d'attaque est intimement liee à ces personnages. Il n'y a que un personnage qui puisse attaquer, donc on associe cette "action" aux personnages en mettant ça dans une classe.


          Je suis d'accord, la syntaxe est plus naturelle, mais bon c'est plus philosophique que pratique non ?

          Pour les attributs en private, ca serait dans le cadre d'une librairie non ? pour éviter qu'on fasse n'importe quoi avec les objets par exemple

          en tout cas j'attends avec impatience la suite du cours ^^
          • Partager sur Facebook
          • Partager sur Twitter
            27 juin 2007 à 16:36:15

            Non c'est pas seulement philosophique, mais pour que tu puisses le comprendre il faut que tu vois le polymorphisme et l'héritage qui sont deux des piliers de la programmation objet et qui font tout son intérêt.

            Attention Nanoc, les templates ne sont pas représentatifs de la POO, c'est un concept à part introduit par C++. D'autres langages orientés-objets ne possèdent pas ce concept.

            En ce qui concerne l'encapsulation, le principe n'est pas d'associer les données et les méthodes. Il est tout à fait possible de faire de l'encapsulation en C et les fonctions ne sont pas attachées aux objets (cf Type Opaque).
            Le principe de l'encapsulation c'est surtout de pouvoir protéger l'intégrité des données. Je vais reprendre ton exemple de compte en banque. Pour pouvoir augmenter et diminuer la some d'argent que tu as dans ton compte tu as deux méthodes créditer() et débiter(). L'encapsulation permet de réserver à ces deux méthodes la modification de la somme d'argent dans ton compte. Si les données n'étaient pas dans une "capsule" hermétique, n'importe qui pourrait faire : monCompte->solde += 1000000. Je suis pas sûr que les banquiers seraient d'accord. :D Donc on protège les données dans leur type, et c'est seulement après avoir protégé les données que la notions de fonctions ou méthodes qui manipulent ces données apparaît.
            • Partager sur Facebook
            • Partager sur Twitter
              27 juin 2007 à 16:49:27

              Citation : Psycoh13

              Attention Nanoc, les templates ne sont pas représentatifs de la POO, c'est un concept à part introduit par C++. D'autres langages orientés-objets ne possèdent pas ce concept.



              Entièrement d'accord. Je n'aurais pas dû le mettre là.
              • Partager sur Facebook
              • Partager sur Twitter
              Co-auteur du cours de C++. ||| Posez vos questions sur le forum ||| Me contacter.
                27 juin 2007 à 22:45:24

                +1 au fait que l'encapsulation est un principe du monde OO, limite un outil au service de l'abstraction : on expose aux clients uniquement ce dont ils ont besoin pour accéder aux services que l'on fournit.

                L'encapsulation, c'est un peu comme le fait que les rouages internes de la serrure de la porte d'entrée chez toi ne sont pas visibles, ni manipulables. A la place, tu tournes une clée et appuies sur une poignée.


                Ce qui fait vraiment la différence, c'est le polymorphisme d'inclusion que tu verras en temps et en heure. Faire la même chose en C demande beaucoup d'huile de coude, et d'être bien réveillé.
                • Partager sur Facebook
                • Partager sur Twitter
                C++: Blog|FAQ C++ dvpz|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS| Bons livres sur le C++| PS: Je ne réponds pas aux questions techniques par MP.
                  28 juin 2007 à 0:12:26

                  Je rajouterais que ce n'est pas le fait que les fonctions soient dans la structure qui fait que c'est de la POO.

                  Parce qu'on a fait une classe avec des méthodes attributs ne veut pas dire qu'on fait de la POO.

                  Idem, le fait d'écrire goliath.attaquer(david) au lieu de attaquer(david, goliath), c'est plus naturel, mais c'est purement syntaxique.

                  On peut faire de la POO en C, même si le langage ne le supporte pas nativement.

                  La POO c'est une manière de voir les choses. On a un type : la classe, à qui on associe des services, qui respectent des contrats.
                  C'est comparable à programmer sous forme de Types Abstraits de Données, et c'est souvent l'exemple qui est pris pour introduire la POO. On ne s'intéresse pas à l'implémentation, mais aux préconditions, post-conditions.
                  • Partager sur Facebook
                  • Partager sur Twitter
                    28 juin 2007 à 11:20:47

                    Citation : psychoh13


                    Le principe de l'encapsulation c'est surtout de pouvoir protéger l'intégrité des données. Je vais reprendre ton exemple de compte en banque. Pour pouvoir augmenter et diminuer la some d'argent que tu as dans ton compte tu as deux méthodes créditer() et débiter(). L'encapsulation permet de réserver à ces deux méthodes la modification de la somme d'argent dans ton compte. Si les données n'étaient pas dans une "capsule" hermétique, n'importe qui pourrait faire : monCompte->solde += 1000000. Je suis pas sûr que les banquiers seraient d'accord. :D Donc on protège les données dans leur type, et c'est seulement après avoir protégé les données que la notions de fonctions ou méthodes qui manipulent ces données apparaît.


                    Et monCompte.crediter(1000000000) tu crois que ça change quelque chose?
                    Après, je trouve que les

                    private :
                    int bidule
                    public :
                    int getBidule(){ return bidule;}
                    void setBidule(int rien){ bidule=rien; }
                     

                    sont des aberrations pures.
                    • Partager sur Facebook
                    • Partager sur Twitter
                      28 juin 2007 à 11:23:13

                      En effet, c'est pas le but non plus de la POO, de faire des accesseurs et modificateurs.

                      • Partager sur Facebook
                      • Partager sur Twitter
                      Co-auteur du cours de C++. ||| Posez vos questions sur le forum ||| Me contacter.
                        28 juin 2007 à 12:51:36

                        les accesseurs et mutateurs peuvent etre utiles exemple :

                        void setBidule(int i)
                        {
                           if (i > 0) moncompte = i;
                        }


                        ça te permet d'avoir un contrôle sur la variable.

                        • Partager sur Facebook
                        • Partager sur Twitter
                          28 juin 2007 à 12:56:49

                          Bien sûr que si ! Mais tous les accesseurs/modificateurs ne sont pas comme ça, beaucoup diffèrent dans la gestion même. Par exemple, certains modificateurs feront une copie de la nouvelle valeur plutôt qu'une affectation pure et simple. Bien sûr, pour les opérations de base à qui ont donne une simple valeur c'est aberrant, mais le fait de pouvoir protéger les données et d'utiliser un intermédiaire permet de pouvoir, sans modifier l'interface, c'est-à-dire ce qui est visible de l'extérieur par les utilisateurs, de modifier la manière de gérer ces données.

                          Par exemple, en Objective-C où on a à peu prés le même système, c'est-à-dire des attributs qu'on peut mettre à public, protégé ou privé, et des méthodes publiques, dans un modificateur qui modifie un attribut qui est de type objet. On a le choix entre faire une copie de l'objet ou une affectation directe. Quelle est la différence ? Déjà en Objective-C tout passe par des références, enfin on appelle ça des références mais ils 'agit de pointeur sur des structures, mais comme une instance est toujours représentée par un pointeur on parle de référence directement. Donc tout passe par ces références, ce qui fait que plusieurs objets auront comme attribut une référence vers un même objet, le problème c'est que si l'un d'eux le modifie pour tous les autres ce sera modifié aussi, et à ce moment pour les autres ça pourra poser des problèmes.
                          Donc, si le modificateurs fait une copie de l'objet pour pouvoir avoir sa propre référence privée, mais qu'on laisse l'attribut publique, c'est-à-dire qu'on laisse n'importe qui modifier l'attribut lui-même, ça posera sans doute des problèmes d'intégrité des données.
                          Autre chose, l'utilisation de modificateurs et d'accesseurs, j'ai dit plus tôt que ça permettait de modifier l'implémentation sans modifier l'interface. Ça aussi c'est important, l'implémenteur d'une classe peut s'il le souhaite modifier le fonctionnement interne de sa classe, peut-être qu'il va incrémenter la valeur de "rien" avant de l'affecter à "bidule" parce qu'il aura changé l'utilisation de bidule dans une autre méthode, mais il fera tout ça sans pour autant modifier l'interface.
                          C'est-à-dire que tous les programmes qui utilisent la classe que l'implémenteur aura programmé, n'auront pas à réécrire leur code quand ils utiliseront la nouvelle version.

                          L'encapsulation permet donc de protéger l'intégrité des données mais aussi d'éviter que les utilisateurs aient à se soucier de ce qu'il y a à faire pour que les données ne soient pas corrompues en donnant une interface qu'ils pourront utiliser sans peine.
                          • Partager sur Facebook
                          • Partager sur Twitter
                            29 juin 2007 à 17:55:05

                            merci, je vais voir ça, merci pour vos réponses, ca s'éclaircit un peu ( vivement la suite de cours !! je crois que je vais prendre un peu d'avance sur developpez.com lol )
                            • Partager sur Facebook
                            • Partager sur Twitter

                            Bénéfices concrets de la POO ??

                            × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                            × Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
                            • Editeur
                            • Markdown