Les classes

Utilité et principe

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour,

Je suis un débutant en programmation (j'ai réellement commencé à m'intéresser à la programmation en juin dernier ^^) et je bute actuellement sur un concept : celui de Classe.

Voici mes questions à ce propos :)
- Quel est l'utilité d'une classe (on me l'a déjà expliqué mais je n'ai pas compris, je cherche donc d'autres façons de le voir :) ) ?
- Comment savoir quand on en a besoin/ou pas ?
- Comment présenter/compléter une classe (qu'est ce qu'on y met ou pas) ?
- Comment savoir qu'on doit utiliser l'héritage (et je ne comprends pas bien l'héritage non plus d'ailleurs ^^) ?
- Comment utiliser clairement l'héritage :) ?

Je ne vous demande pas des solutions miracles, juste votre point de vue sur tout cela :) qui sait ? Peut être que je comprendrais soudain en lisant l'un d'entre vous ou plusieurs mélangés ^^

Édité par Poliorcetics

Hey, moi c'est polio, et je te souhaite une bonne lecture :p !

+0 -0

En partant d'un cas concret, on pourrait donner un jugement expérimenté sur ta façon de résoudre un problème.

Dans ton cas, l'utilisation d'un moteur de recherche est amplement suffisant pour te documenter et répondre aux questions que tu te posent.

+3 -2

Cette réponse a aidé l'auteur du sujet

Une classe, c'est un peu comme une boite à outils.

Voici mon expérience de développeur 'ancien', formé à une époque où les classes n'existaient pas. Et donc comme toi, pas très convaincu par les classes quand j'ai commencé à les croiser.

Pour moi, il existe 2 types de classe.

  1. La classe boite à outils. Par exemple, tu développes une série d'outils pour accéder aux contacts facebook, aux profils FB, au bouton like FB. Et tu veux partager cette boite à outils avec d'autres développeurs, et leur donner accès au code qui tu as écrit. Tu vas donc créer une classe 'facebook'. C'est le premier type de classe. Les informaticiens les plus intégristes vont dire que ce n'est pas une classe. Soit. Dans la pratique, je pense que cette utilisation des classes est assez importante.

  2. La classe 'Objet'. On est là en pleine POO. L'exemple typique, tu développes un jeu. Il y a donc une scène de jeu, et des objets sur cette scène de jeu. Par exemple des véhicules. En programmation classique ( sans les classes), on faisait : Déplace( véhicule[i]) En POO, on fait en gros : Vehicule[i].Deplace() : on appelle la méthode Deplace de la classe vehicule() Le code de la fonction Deplace() est dans la classe Vehicule.

Si on a 20 véhicules sur la scène de jeu, on va donc instancier 20 fois la classe véhicule.

Quel est l'intérêt de ""déporter"" la fonction déplace Dans la classe Vehicule, au lieu de la garder dans le programme principal ?

Ca permet essentiellement de simplifier la programmation. Si par exemple, dans notre jeu, on gère des avions et des voitures, au niveau du programme principal, c'est transparent. Dans les 2 cas, on appelle la fonction deplace() de la classe vehicule. Et par un système d'héritage, suivant que le véhicule est un avion ou une voiture, la méthode Deplace gérera un déplacement en 2 dimensions, ou en 3 dimensions.

Pour organiser le travail de développement, c'est très pratique. Sur un gros projet, on va définir au départ les différentes méthodes. Puis un programmeur sera en charge de la classe, alors qu'un autre programmeur sera en charge du programme principal. La classe est comme une boite noire. Comment le véhicule accélère, ralentit, quelle est son inertie … tout cela est programmé une fois pour toute dans la classe Véhicule. La majorité des variables qui servent à gérer la classe seront des variables privatives, non visibles de l'extérieur de la classe.

En fait, le programme principal voit la voiture se déplacer, mais il ne voit pas ce qui se passe dans le moteur, il ne voit pas si le réservoir est quasi-vide. Par contre, le programme principal voit si les clignotants sont allumés.

Idem, dans un jeu type jeu de poker, le programme principal ne voit pas les cartes des joueurs, il voit uniquement leurs mises. Ca évite les erreurs de programmation, où le programme miserait en fonction des cartes de l'adversaire !

+4 -0
Auteur du sujet

C'est beaucoup plus clair que ce que j'avais pu trouver :) merci :D !

Me reste "plus qu'à" comprendre la notion d'héritage et ce sera bon ^^

Édité par Poliorcetics

Hey, moi c'est polio, et je te souhaite une bonne lecture :p !

+0 -0

Pour rester avec notre exemple de véhicule, la notion d'héritage est assez simple à illustrer.

La classe principale s'appelle VEHICULE. Un véhicule va avoir différentes propriétés (couleur, taille, vitesse maximale, vitesse actuelle, position, clignotant allumé ou non ) et différentes méthodes ( démarrer, ralentir, tourner, allumer_clignotant)

A partir de ce schéma général, valable pour tous les types de véhicules, on va souvent vouloir aller plus loin. Parmi les véhicules, il y a les vélos, les voitures, les camions… C'est là que la notion d'héritage intervient. On va donc créer une classe parent : vehicule, et des classes filles : Voiture / velo / camion… Chaque type de véhicule aura en plus des propriétés et des méthodes générales, d'autres propriétés et d'autres méthodes spécifiques.

Ca permet de programmer une fois pour toutes un comportement standard pour tous les types de véhicules. Par exemple, la fonction allumer_clignotant sera la même pour les voitures, les motos et les camions. Le code de la fonction Allumer_clignotant sera dans la classe Vehicule, et pas dans les autres classes. Par contre, pour la classe Velo, on va créer une fonction allume_clignotant qui aura comme code un truc du genre :

allumer_clignotant() Renvoyer 0 // On ne peut pas allumer les clignotants sur un vélo.

Pour un objet de la classe Velo, cette fonction 'remplacera' la fonction allumer_clignotant commune à tous les autres types de véhicules.

On a donc: - Les méthodes de la classe véhicule. - Les méthodes de la classe 'fille', qui portent le même nom qu'une méthode de la classe mère, et qui remplacent le comportement standard. (on parle de surcharge de méthode) - Et aussi, on peut avoir des méthodes propres à chaque classe fille. Par exemple, dans la classe camion, on va avoir une méthode supplémentaire qui est vider_remorque()

L'intérêt de l'héritage est toujours le même : diviser le travail de programmation en petits morceaux, indépendants les uns des autres, et éviter les redondances. Un principe important en développement, c'est de ne pas copier/coller les mêmes portions de code à différents endroits. La fonction allumer_clignotant est commune à la classe moto et à la classe camion, on la place donc à un niveau plus haut, dans la classe véhicule.

+0 -0

J'ai retrouvé mes deux analogies pour présenter l'OO (les classes) et le polymorphisme -> http://openclassrooms.com/forum/sujet/comment-le-c#message-87210210
(ma vision de l'héritage n'est pas orienté factorisation de petits bouts communs (qui marche assez mal quand on ne peu pas sortir des hiérarchies propres, cf l'émergence des ECS), mais factorisation de grosses parties communes où des points de variations sont requis)

+1 -0
Staff

Eh bien dans le tuto Python tu vas être servi : en Python une classe est exactement la même chose qu'un type puisque tout ce que tu manipules dans les programmes est un objet.

Python repose sur un concept de classe très simple qui permet réellement de construire le langage en utilisant les objets comme des LEGO. Ça t'aidera sûrement à en comprendre la philosophie de base.

Édité par nohar

I was a llama before it was cool

+2 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte