Discussion :

[Papyllon]

Bonjour,

J'utilise le langage python régulièrement depuis peu et ai appris en autodidacte. Pour l'instant, tous mes scripts utilisent des fonctions.

J'ai beau lire plusieurs tutoriels, la définition des classes est toujours sous-entendue et je n'arrive pas saisir la subtilité des classes.

Je souhaiterais une explication claire sur l'utilité d'utiliser des classes plutôt que des fonctions mais aussi sur la différences entre les classes et les fonctions.

Peut-être avez-vous un lien ou un texte claire à me conseiller?

Merci.

edit: je viens de lire un des tutoriels proposé par ce site, notamment la partie "utilité des classes", ce qui répond en partie à mon sujet.

[Zavonen]

Votre question n'a rien à voir avec le langage python.
Tous les langages utilisant une 'couche objet (C++, Java, etc...) proposent la possibilité de fabriquer des classes pour modéliser des objets.
Je vous conseille donc de lire des choses accessibles sur la notion de 'programmation orientée objet'. Ensuite tout devient évident.
Un des mérites de python est de ne pas imposer (comme java) une approche particulière. On peut très bien mélanger les classes et les fonctions. Les fonctions peuvent admettre des classes en argument, les instances de classes peuvent appeler des fonctions définies en dehors de la classe.

[Sve@r]

Je souhaiterais une explication claire sur l'utilité d'utiliser des classes plutôt que des fonctions mais aussi sur la différences entre les classes et les fonctions.

Petit résumé rapide
- une fonction retranscrit généralement un algorithme "utile à tous" ou bien "qui n'a pas forcément nécessité d'être impliquée dans un objet"
Exemple: calcul de md5 => l'approche intuitive sera une fonction à laquelle on passe une grosse string et qui renvoie le md5. S'il faut calculer le md5 d'un fichier ben on pourra alors stocker le fichier dans la string (sans présumer des problèmes éventuels d'espace mémoire nécessaire au stockage)

- un objet retranscrit généralement la façon dont on perçoit les outils que l'on crée.
Exemple: si je dois créer un outil pour gérer une fraction mathématique, alors je m'orienterai plus généralement ver un objet "cFrac" contenant
- un numérateur
- un dénominateur
A cet objet, j'associerai des fonctions qui lui sont intuitivement liées et dépendantes. Par exemple il pourra y avoir une fonction "reduce" chargée de transformer une fraction 2/4 en 1/2. Cette fonction "reduce "ayant aucune raison d'être en dehors d'une fraction deviendra une méthode de cet objet et lui sera alors totalement liée.

Ensuite tout le reste c'est une question de perception personnelle. Vaut-il mieux un objet ou une fonction...

Exemple: il existe une fonction len() chargée de donner la longueur d'un élément qu'on lui passe. On lui passe une string la fonction donne la longueur de la chaine. On lui passe un tableau, la fonction donne le nb d'éléments du tableau. Pourquoi n'y a-t-il pas de méthode "len" spécifique à l'objet "str" ? Ben parce que les programmeurs ont préféré orienter leur travail dans une autre direction...

[wiztricks]

Salut

Pour le coup, je trouve cela quand même un peu 'rapide'.
Une forme plus zen pourrait être de dire:

Les classes et les modules sont entités qui encapsulent:

1. des éléments de type attributs/variables dont les valeurs définissent ce qu'on appelle un 'état'
2. des fonctions/méthodes dont le comportement pourra dépendre de cet "état" et se distinguent par la façon dont on va pouvoir y accéder.

Dit autrement ce sont d'abord des boîtes qui servent à regrouper des éléments communs(*).

Les fonctions ne sont pas à proprement parler des "boîtes" - en Python si, mais ce n'est plus du 'basique'.

L'effet "boîte".

Soit mon_module.py contenant la fonction f et la variable a:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
# file: mon_module.py
a = 1
def add(inc):
    """ajoute inc a 'a'"""
    global a
    a += inc
def get():
    return a

Nous pourrons l'utiliser ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
import mon_module
print mon_module.get() # affiche la valeur de "a"
mon_module.f(2) # ajoute 2 a "a"

Dans le cas des modules, "l'état" (matérialisé par la variable "a") est "unique" et donc "global".

Imaginons que nous voulions créer des "états spécifiques" (sans pour autant parler de "classes", j'appelle ca MyClass pour faciliter les comparaisons).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
# file: MyClass.py
def new_state(v):
      return dict(a=v)
def add(state, inc):
    state['a'] += inc
def get(state):
    return state['a']

Nous pourrions l'utiliser ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
import MyClass
instance1 = MyClass.new_state()
instance2 = MyClass.new_state()
MyClass.add(instance1, 2)
print MyClass.get(instance1)

Cette technique est utilisée dans les langages non objet pour associer un ensemble de fonctions à des ensembles de variables - "state" -.

La notion d'objet est définie par ces entités "similaires" car:

• partageant un ensemble de variables communes pouvant prendre des valeurs spécifiques - leur état -,
• définissant un ensemble de "fonctions" pouvant leur être appliqué et dont le comportement pourra dépendre de l'état.

Ces fonctions associés devront avoir au moins un paramètre: l'état.
Différentes d'une fonction quelconque, on les appellera "méthode".

Et les vraies classes dans tout çà? A la base, c'est ce que propose le langage de programmation pour définir une boîte qui réalise cette association entre des méthodes et différents états appelées "instances".

Reprenons l'exemple.
En utilisant des "class", il devient...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
# plus besoin de creer un script pour fabriquer une boite, "class" suffit:
class MyClass:
      # init est la méthode qui permet d'initialiser les variables d'etat.
      def __init__(self, v):
           self.a = v
      def add(self, inc):
           self.a += inc
instance1 =  MyClass(1) # creation de l'instance 1
instance2 =  MyClass(1) # creation de l'instance 2
instance1.add(2) # n'incrémente que la copie "a" de instance1
print instance1.get()

Qu'est ce qui a changé?

• La construction d'une instance: instance1 = MyClass(1) permettant de passer des valeurs pouvant être utilisées pour initialiser l'instance à la méthode __init__.
• 'self' : nom donné par convention au premier paramètre d'une méthode. permet de savoir de quelle instance/"état" nous aurions pu l'écrire.
• appel de méthode: instance1.add(2) s'écrit aussi MyClass.add(instance1, 2).

Il s'agit en gros de conventions d'écriture, un standard.

Le base de chez base des différences et des similitudes entre:
- modules et classes : une boite / des boîtes!
- fonctions et méthodes : méthode = fonction + contexte/état.

Ajoutons y des éléments de modélisation des connaissances telles que héritage, polymorphisme,... Le sujet devient bien plus touffu.

Épaississons encore avec des relations particulières qu'on va pouvoir construire entre ces objets... Et voilà la POO et les patterns de conception.

A quoi çà sert?
Créer des boites et des relations entre elles est un travail d'architecture ou de conception. Les buts de ce genre d'activité sont d'organiser, mettre en forme pour pouvoir construire un "programme" qui réalise les fonctionnalités attendues.
Note: Il s'agit des Utilitas, Firmitas, Venustas de Vitruvius

Ce genre d'artillerie devient appréciable lorsqu'on commence à avoir beaucoup de concepts, d'objets, d'états, de relations à 'ranger', construire.
(et ce n'est pas nécessairement utile qu'à la construction de logiciels).

Lorsqu'on débute, on se lance dans des projets "simples" et passer par la POO est plus souvent "scolaire" - il faut bien apprendre - que nécessaire.

- W

[dividee]

Magnifique réponse, wiztricks

Note: Il s'agit des Utilitas, Firmitas, Venustas de Vitruvius

Là je me demande si tu es architecte ou romaniste

Lorsqu'on débute, on se lance dans des projets "simples" et passer par la POO est plus souvent "scolaire" - il faut bien apprendre - que nécessaire.

Même si je suis un "pythoniste" convaincu, je me demande si c'est le langage idéal pour apprendre la POO. Il vaut peut-être mieux passer par un langage qui force à faire de la POO (il y a du choix: Java, Eiffel, C#, Smalltalk, ...) plutôt que d'utiliser un langage "multiparadigme" comme Python, où on aura tendance à la moindre difficulté à se rabattre sur ce qu'on connait...

[wiztricks]

Même si je suis un "pythoniste" convaincu, je me demande si c'est le langage idéal pour apprendre la POO. Il vaut peut-être mieux passer par un langage qui force à faire de la POO (il y a du choix: Java, Eiffel, C#, Smalltalk, ...) plutôt que d'utiliser un langage "multiparadigme" comme Python, où on aura tendance à la moindre difficulté à se rabattre sur ce qu'on connait...

Certes!
Je dirais que Python est bien pour s'initier et pour ceux qui savent déjà.
Ceux qui ont l'ambition d'être programmeurs/concepteurs doivent prendre le temps de gouter d'autres langages et d'en pratiquer intensément certains des familles Prolog, Lisp, C++, ...
Maintenant, nous ne sommes plus dans les années 70s! Depuis, nous avons construit et reconstruit tout ce qui devait être fait avec rigueur: je ne suis pas certain qu'apprendre à construire un compilateur aujourd'hui ait grand intérêt pour les masses! Bien que cela reste une spécialité intéressante.
- W

[afranck64]

salut,

Alors vous pensez vraiment aue le python n est pas fait pour apprendre le POO?
avant je codais juste avec Pascal. Et la vous faites un peu peur car j ai toujours pense que le python serait mon arme ultime pour les codes.

[wiztricks]

salut,

Alors vous pensez vraiment aue le python n est pas fait pour apprendre le POO?
avant je codais juste avec Pascal. Et la vous faites un peu peur car j ai toujours pense que le python serait mon arme ultime pour les codes.

C'est très bien pour s'initier à...
Ceci dit, pour moi la POO est plus un outil de conception plus qu'une technique de programmation.
- W

[Zavonen]

Je dirais que Python est bien pour s'initier et pour ceux qui savent déjà.

Petite phrase apparemment paradoxale mais on ne peut plus vraie. Que j'approuve donc totalement.

[rambc]

Petite phrase apparemment paradoxale mais on ne peut plus vraie. Que j'approuve donc totalement.

Point de paradoxe. Pourquoi la complexité ne serait-elle pas simple ?

[bretus]

Alors vous pensez vraiment aue le python n est pas fait pour apprendre le POO?

Je pense que ça serait une mauvaise chose car il manque des mots clés usuels dans la couche objet de Python et que l'on se retrouve très vite à y faire un bricolage infâme.

Dès le début, l'absence du "this" en contexte qui oblige à passer "self" en argument l'écarte de la plus part des langages disposant d'une couche objet... Il faut une bonne vision de l'objet et des mécanismes internes des interpréteurs pour comprendre pourquoi il en est ainsi <troll>et virer de suite python des langages candidats à un amour sans égal</troll>.

Comme il manque dans la couche objet de python des mots clés correspondant à des notions "avancées" de l'objet, vous risquez entre autre de passer à côté du principe des méthodes abstraites et du principe d'interface... Si l'utilisateur peut s'adapter à l'absence des mots clés, quand il connais les concepts, je ne pense pas qu'aborder les méthodes abstraite en les émulant à coup de "raise NotImplementedError" soit une bonne habitude à prendre...

J'aurais donc tendance à vous conseillez de vous éloignez de Python le temps de saisir les principaux concepts de la programmation objet. En revenant à Python, vous aurez pas trop de problème à comprendre comment on se passe de la présence de certains mots clés en Python (tel "this"...).

En essayant d'apprendre l'objet au travers de Python, on risque surtout d'apprendre à émuler l'absence de mots clés présent dans des <troll>langages disposant d'une vrai couche de P.O.O.</troll>. A contrario, en abordant l'objet en apprenant Java, on comprend les concepts au travers de la présentation des mots clés...

PS : Une fois que vous aurez bien compris l'objet, vous pourrez souffrir les petits défauts de Python pour l'efficacité qu'il offre face à Java sur les choses simples ;] (oui oui, je ne veux pas finir sur un bucher)

[wiztricks]

re.-1
Ah ben, le salaire d'un programmeur expérimenté C++ ou Java se mérite!!!
En fait, il y a tellement de trucs à considérer pour écrire un peu de code qu'on en oublie pourquoi on code
- W

[Zavonen]

Pourquoi la complexité ne serait-elle pas simple ?

J'avais appris dans ma jeunesse que les choses complexes étaient les choses dont on ne pouvait dire qu'elles étaient simples. Bref que les notions de 'simple' et 'complexe' étaient antinomiques. Il semble que dans la "novlangue" cela ne soit plus le cas. Dont acte!
Dur de rester 'in' ...

[rambc]

J'avais appris dans ma jeunesse que les choses complexes étaient les choses dont on ne pouvait dire qu'elles étaient simples. Bref que les notions de 'simple' et 'complexe' étaient antinomiques. Il semble que dans la "novlangue" cela ne soit plus le cas. Dont acte!
Dur de rester 'in' ...

C'est juste une phrase "marketing"...

[Zavonen]

et virer de suite python des langages candidats à un amour sans égal

Si je peux me permettre d'en rajouter une couche. Mon conseil:
Virez TOUS les langages des candidats à un amour sans égal.
Avec une jolie fille c'est déjà risqué, mais on a vu des cas où ça fonctionne, mais avec des langages c'est perdu d'avance, on est toujours cocu.

[bretus]

re.-1
Ah ben, le salaire d'un programmeur expérimenté C++ ou Java se mérite!!!
En fait, il y a tellement de trucs à considérer pour écrire un peu de code qu'on en oublie pourquoi on code
- W

Il est sur que les règles d'utilisations du C++ ne sont pas piquées des verres et que l'effort d'apprentissage est assez redoutable... Par contre, une fois que l'on passe le cap et que l'on utilise un framework de haut niveau (Qt par exemple), il s'avère plus efficace sur bien des sujets...


Java est verbeux, mais bon, vu que le langage est très carré, l'auto-complétion est très abouties et fait gagner un temps sérieux... Ensuite, il est sur que quand on débute avec Java, C# ou Qt, l'architecture du framework parait bien compliquée pour rien faire. Ce n'est que quand le projet se complique que l'on en comprend l'intérêt... Par contre, on apprend les bonnes pratiques de l'objet à mesure que l'on comprend comment les classes de base du langage sont gaulées, ce qui est plutôt "agréable".


Après, perso je n'aime pas vivre dans la peur de recevoir le mail intitulé [BUG] "Je reçois le message la fonction machinTruc de la classe MachinTruc n'est pas implémentée!"...

[kango]

bonsoir,

post intéressant que celui-ci

Je pense que ça serait une mauvaise chose car il manque des mots clés usuels dans la couche objet de Python et que l'on se retrouve très vite à y faire un bricolage infâme.

des mots clés usuels dans d'autres langages Je m'explique, le modèle objet de C++ par exemple est très rigide à mon goût (la nécessité des public, private, protected) ce qui pourrait être considéré comme une force. Mais dans le même temps, il met à disposition des moyens de contournement (les relations d'amitié). Je trouve que c'est une belle ambiguité dans la couche objet de C++ Et si on n'a rien compris à l'encapsulation, je pense qu'on peut voir de belles cochoneries en C++ aussi avec ça

Dès le début, l'absence du "this" en contexte qui oblige à passer "self" en argument l'écarte de la plus part des langages disposant d'une couche objet...

Là encore, je perçois le "this" comme une exception: il y a une règle qui tend à ne pas avoir à l'employer mais bon parfois il le faut parce qu'on peut pas faire autrement. La présence, répétée et pénible de self selon toi, permet à mon sens une cohérence bien meilleure.

Comme il manque dans la couche objet de python des mots clés correspondant à des notions "avancées" de l'objet, vous risquez entre autre de passer à côté du principe des méthodes abstraites et du principe d'interface... Si l'utilisateur peut s'adapter à l'absence des mots clés, quand il connais les concepts, je ne pense pas qu'aborder les méthodes abstraite en les émulant à coup de "raise NotImplementedError" soit une bonne habitude à prendre...

Je suis d'accord sur les interfaces. Même si plusieurs librairies implémentent des notions parfois un peu différentes (la zca, PyProtocols) j'aimerais vraiment les voir débarquer dans la librairie standard. Donc rien ne nous empêche d'utiliser des interfaces en Python. Je les utilise au quotidien. C'est un outil extrêmement puissant, peut être encore plus en Python du fait de son typage dynamique et de l'héritage multiple par exemple (je parle du fameux duck typing). Le modèle objet de Python (soit disant pas bon) permet d'implémenter facilement cette notion d'interface. De l'autre côté, certains peinent avec l'héritage multiple . Je trouve même que la notion d'interface en Python dépasse celle de Java par exemple, dans le sens où en Java, on se défend souvent de l'héritage multiple en prétextant les interfaces. En Python, on a les deux, et moi, j'aime ça.

J'aurais donc tendance à vous conseillez de vous éloignez de Python le temps de saisir les principaux concepts de la programmation objet. En revenant à Python, vous aurez pas trop de problème à comprendre comment on se passe de la présence de certains mots clés en Python (tel "this"...).

A la fois d'accord et pas d'accord. Je pense que c'est une bonne idée de voir le modèle objet de Python et d'un autre langage à côté. De là à s'éloigner complètement de Python...

En essayant d'apprendre l'objet au travers de Python, on risque surtout d'apprendre à émuler l'absence de mots clés présent dans des <troll>langages disposant d'une vrai couche de P.O.O.</troll>. A contrario, en abordant l'objet en apprenant Java, on comprend les concepts au travers de la présentation des mots clés...

hmm, absence de mots clés en Python ou abondance injustifiée dans d'autres ? On peut tout à fait choisir de faire de très longues phrases pour exprimer une idée simple qui ne nécessite que quelques mots. La concision n'est pas un signe de défaillance intellectuelle mais une qualité. Mais je comprends que pour expliquer certains détails superflus, on puisse avoir besoin d'inventer des mots

[kango]

Java est verbeux, mais bon, vu que le langage est très carré, l'auto-complétion est très abouties et fait gagner un temps sérieux...

quel rapport entre Java et l'autocomplétion ? Il n'y a pas d'autocomplétion en Python, en C++ ??? Ce n'est pas une caractéristique du langage mais des éditeurs.

<troll>et s'il n'y a que ça pour faire gagner du temps en Java, ça donne pas très envie </troll>

Par contre, une fois que l'on passe le cap et que l'on utilise un framework de haut niveau (Qt par exemple), il s'avère plus efficace sur bien des sujets...

euh.. quel rapport ? On a aussi Qt en Python Et Python est encore plus concis avec ça :p (mais où s'arrêtera t'il !)

Python souffre je pense du fait qu'il ne soit pas encore enseigné à grande échelle dans les écoles ou les universités (comparativement à Java ou C++ éventuellement). Dés lors, une grande partie de la population considère que la référence c'est Java ou C++ et qu'il "manque" des choses à Python. C'est un point de vue. Mais je ne le partage pas Je crois qu'on l'a compris

Je pense qu'il y a tout un tas d'arguments qui font que Java est un bon langage et même le C++. C'est juste que là, tu es pas arrivé avec les bons arguments

[dividee]

En essayant d'apprendre l'objet au travers de Python, on risque surtout d'apprendre à émuler l'absence de mots clés présent dans des <troll>langages disposant d'une vrai couche de P.O.O.</troll>.

Je ne pense pas qu'on risque d'émuler ce qu'on ne connait pas. Mais c'est effectivement là le problème, on aura du mal à apprendre ces concepts si on ne connait que Python.

Et Python possède une vrai couche objet. Dans un sens, il est plus OO que Java vu qu'en Python tout est objet (un entier est un objet, une méthode, même une classe); on peut difficilement faire plus objet que ça. En Java, les types primitifs ne sont pas des objets (ce qu'on doit compenser avec du "boxing") et on doit parfois utiliser une inner class pour compenser le fait qu'une méthode n'est pas un objet...

Donc rien ne nous empêche d'utiliser des interfaces en Python. Je les utilise au quotidien.

Rien ne l'empêche ? Peut-être, mais honnêtement, as-tu appris initialement le concept d'interface en Python ? Cela m'étonnerait...

quel rapport entre Java et l'autocomplétion ? Il n'y a pas d'autocomplétion en Python, en C++ ??? Ce n'est pas une caractéristique du langage mais des éditeurs.

Ben si le langage a une influence sur la qualité de l'autocomplétion. En Java, une simple analyse syntaxique suffit généralement pour l'autocomplétion, en Python c'est beaucoup plus difficile car sans exécuter le code, on ne peut pas être sur du type d'un variable (en fait, on ne peut même pas être sûr qu'elle existe). C'est l'un des avantages du typage statique... Je suis souvent déçu de la qualité de l'autocomplétion en Python, mais je sais pourquoi elle est médiocre.
En C++ c'est plus complexe aussi, car le typage peut être contourné (héritage du C), et la métaprogrammation par templates complique peut être aussi les choses (pas sûr, à voir).

Python souffre je pense du fait qu'il ne soit pas encore enseigné à grande échelle dans les écoles ou les universités (comparativement à Java ou C++ éventuellement). Dés lors, une grande partie de la population considère que la référence c'est Java ou C++ et qu'il "manque" des choses à Python.

Je suis partiellement d'accord, mais il serait encore plus néfaste de considérer Python comme la référence en matière d'orientation objet. Python a une couche OO intéressante et relativement simple de par le typage dynamique; certains concepts ne prennent vraiment un sens qu'en typage statique (par exemple, le polymorphisme et les génériques) et ce serait dommage de passer à côté.

[Zavonen]

Une des lacunes majeures de la couche objet de python est l'absence de véritables constructeurs rendant impossible la promotion automatique de type, qui est à mon avis un mécanisme fondamental permettant l'identification. C'est par exemple ce principe qui nous permet d'assimiler les entiers à certains rationnels, les rationnels à certains réels, les réels à certains complexes, etc..
Ainsi des écritures telles que r=2 où r est un rationnel prennent tout leur sens devant être comprises comme r=2/1
ou bien x=3/2 quand x est un réel
ou bien encore z=2 quand z désigne un complexe.
Voici donc deux exemples simples et parallèles l'un en python l'autre en C++

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class Truc():
    def __init__(self,x):
        self.value=x
    def __add__(self,y):
        return self.value+y.value
 
A=Truc(1)
B=Truc(2)
print A+B
print A+2
 
""" résultat
3
AttributeError: 'int' object has no attribute 'value'
"""

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#ifndef TRUC_H
#define TRUC_H
#include <iostream>
using namespace std;
 
class Truc
{
    public:
        Truc(int);
        virtual ~Truc();
        friend Truc operator+(Truc,Truc);
        void show();
    protected:
    private:
    int value;
};
 
#endif // TRUC_H

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
#include "Truc.h"
 
Truc::Truc(int n)
{
    //ctor
    value=n;
 
}
void Truc::show(){
    cout<<value<<"\n";
}
Truc::~Truc()
{
    //dtor
}
Truc operator+(Truc T1, Truc T2) {
return Truc(T1.value+T2.value);
}

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
#include "Truc.h"
int main()
{   Truc T1(1);
    Truc T2 =2; // Cette syntaxe réalisant l'identification n'est pas admise en python
    (T1+T2).show(); // addition 'normale' de deux Trucs
    (T1+4).show(); // promotion automatique de l'opérande de droite (impossible en python)
    (5+T2).show(); // promotion automatique de l'opérande de droite (impossible en python)
    return 0;
}