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