méthode de classe / méthodes d'objet

a marqué ce sujet comme résolu.

Bonjour,

Je m’initie à la programmation objet ; une question concernant les méthodes me turlupine. En instanciant un objet, les méthodes implémentées sont celles de la classe. Autant les attributs d’un objet varient d’un objet à l’autre, autant les méthodes sont les mêmes. J’ai dû mal à imaginer que le code des méthodes de la classe est dupliqué autant de fois qu’il y a d’objets. Est-ce le cas ? sinon, je vois mal ce qui différencie les méthodes d’objet et les méthodes statiques qui ne sont appelables que depuis la classe.

Merci d’avance pour l’aide que vous pourriez m’apporter

Salut,

Le fonctionnement peut varier d’un langage à l’autre. Dans certains il est possible d’avoir des méthodes qui soient réellement propres aux objets (et donc différent d’un objet à l’autre).

Mais généralement la méthode n’existe qu’au niveau de la classe, oui. C’est au mécanisme de résolution des appels de s’occuper de retrouver la méthode lorsqu’elle est appelée depuis un objet.

La différence avec les méthodes statiques ? C’est que l’objet courant est passé dans le contexte de l’appel, ce qui est rudement pratique.

Merci pour l’explication ! Le choix de ne pas allouer inutilement de la mémoire pour dupliquer du code me paraît logique. Dans ce que j’ai lu sur C#, je n’ai pas vu d’exemple impliquant des méthodes au niveau des objets mais cela peut tenir à ma "jeunesse" dans ce domaine.

Quand vous dites que "c’est l’objet courant qui est passé dans le contexte de l’appel", est-ce que je comprends bien en écrivant que l’objet est passé en tant que paramètre à la méthode de classe ?

D’avance merci.

Pour les méthodes (statiques) de classes, il n’y a pas de notion d’objet courant et C::f() <=> f().

Je ne vois pas de tag spécifique C#, alors je me permets de réagir: il y a des langages où C::F() correspond bien à une forme de f(C).

Si je me souviens bien, ça peut être le cas en python suivant le décorateur qu’on utilise.

+0 -0

Pour les méthodes (statiques) de classes, il n’y a pas de notion d’objet courant et C::f() <=> f().

Je ne vois pas de tag spécifique C#, alors je me permets de réagir: il y a des langages où C::F() correspond bien à une forme de f(C).

Je ne comprend pas vraiment. De base en Python, il n’y pas de contexte d’instance pour une méthode « statique ».

class Test():
    def __init__(self):
        pass

    def foo():
        print("Bonjour")


Test.foo()

Je ne vois pas le lien avec les décorateurs.

+0 -0

Je ne vois pas de tag spécifique C#, alors je me permets de réagir: il y a des langages où C::F() correspond bien à une forme de f(C).

Si je me souviens bien, ça peut être le cas en python suivant le décorateur qu’on utilise.

QuentinC

Oui c’est propre à Python et c’est ce qui y différencie les méthodes de classe des méthodes statiques. Mais dans tous les cas l’instance courante n’est jamais passée à ces méthodes.

Je ne comprend pas vraiment. De base en Python, il n’y pas de contexte d’instance pour une méthode « statique ».

Je ne vois pas le lien avec les décorateurs.

ache

Ton code n’est pas très valide, parce que l’appel à la méthode plantera justement s’il est fait depuis une instance de la classe (Test().foo()).

Les décorateurs @staticmethod et @classmethod permettent un comportement identique quel que soit l’objet (classe ou instance) depuis lequel la méthode est appelée.

Les décorateurs @staticmethod et @classmethod permettent un comportement identique quel que soit l’objet (classe ou instance) depuis lequel la méthode est appelée.

Justement, c’est ce à quoi je pensais. Il me semblais que pour un des deux, un self est passé, qui correspond à l’objet Type de la classe.

Paradoxalement, je pensais que la méthode foo de l’exemple posté par ache ne fonctionnait pas, et qu’une des deux annotations étaient obligatoires pour que ça fonctionne correctement.

J’ai lu un mauvais cours ? A l’époque c’était celui de Prolix sur le SDZ. Mais je fais beaucoup plus de Java, de C++, de JavaScript et de PHP que de Python.

+0 -0

C’est un cours qui est en tout cas erroné sur certains points, je ne sais pas pour celui-là. Mais sans décorateur particulier, Test.foo est une fonction tout ce qu’il y a de plus standard.

Donc pour l’appeler directement, il faut lui passer les paramètres qu’elle attend. Si elle n’en prend aucun, on peut l’appeler sans rien.

Là où ça se complique c’est qu’une fonction applique le protocole des descripteurs. Ce qui fait que Test().foo ne sera pas une fonction mais une bound method, faisant en sorte de passer self à chaque appel. C’est comme ça que le code plantera puisque la fonction devrait prendre au moins un paramètre.

staticmethod et classmethod permettent de changer la manière dont l’objet se conforme au protocole des descripteurs. Avec staticmethod, la fonction se renverra toujours elle-même, et avec classmethod elle renverra toujours une bound method appliquée à la classe.

Instant publicité : https://zestedesavoir.com/tutoriels/954/notions-de-python-avancees/3-further/3-accessors-descriptors/

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

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