{"id":138,"date":"2026-09-28T20:41:12","date_gmt":"2026-09-28T18:41:12","guid":{"rendered":"https:\/\/www.ranksignal.fr\/blog\/?p=138"},"modified":"2026-10-04T17:58:19","modified_gmt":"2026-10-04T15:58:19","slug":"de-la-fonction-a-la-classe-python","status":"publish","type":"post","link":"https:\/\/www.ranksignal.fr\/blog\/python\/de-la-fonction-a-la-classe-python\/","title":{"rendered":"De la fonction \u00e0 la classe en Python : le grand saut, pas \u00e0 pas"},"content":{"rendered":"

Ton script tourne. Il est fait de fonctions, chacune fait son travail, et pourtant chaque nouvelle fonctionnalit\u00e9 oblige \u00e0 tra\u00eener une variable de plus d’un appel \u00e0 l’autre. Un jour, tu ouvres le code d’un coll\u00e8gue et tu y trouves self<\/code>, __init__<\/code>, des classes qui h\u00e9ritent d’autres classes.<\/p>\n

Bonne nouvelle : ce saut n’est pas un changement de langage, c’est un changement de rangement. Voici comment le franchir sans te perdre.<\/p>\n

L’essentiel en 30 secondes<\/h2>\n
    \n
  • Une classe<\/strong> regroupe au m\u00eame endroit des donn\u00e9es (ses attributs) et les fonctions qui travaillent dessus (ses m\u00e9thodes).<\/li>\n
  • Le constructeur __init__()<\/code> pr\u00e9pare chaque objet ; les variables d’instance sont propres \u00e0 chaque objet, les variables de classe sont partag\u00e9es.<\/li>\n
  • Les m\u00e9thodes magiques<\/strong> (__str__()<\/code>, __lt__()<\/code>, __iter__()<\/code>\u2026) apprennent \u00e0 tes objets \u00e0 r\u00e9agir aux op\u00e9rateurs et aux boucles de Python.<\/li>\n
  • L’h\u00e9ritage<\/strong> permet de r\u00e9utiliser une classe existante ; le polymorphisme<\/strong> permet \u00e0 une m\u00eame fonction de traiter des objets de classes diff\u00e9rentes.<\/li>\n
  • En Python, rien n’est vraiment priv\u00e9 : c’est une affaire de convention.<\/li>\n<\/ul>\n

    L’intuition : ranger ce qui va ensemble<\/h2>\n

    Imagine un petit jeu \u00e0 deux joueurs. Il te faut deux scores, une op\u00e9ration pour ajouter des points, une pour remettre les compteurs \u00e0 z\u00e9ro, une pour afficher le score et une pour d\u00e9signer le vainqueur. Avec de simples fonctions, il faut passer les scores de l’une \u00e0 l’autre \u00e0 chaque appel, et c’est \u00e0 toi de ne jamais les m\u00e9langer.<\/p>\n

    L’approche orient\u00e9e objet propose autre chose : fabriquer un seul objet<\/strong> qui poss\u00e8de les deux scores et<\/em> sait faire ces quatre op\u00e9rations. Tu ne manipules plus des variables \u00e9parpill\u00e9es, mais un \u00ab suivi de score \u00bb auquel tu donnes des ordres. C’est exactement ce que fait la classe ScoreTracker<\/code> un peu plus bas.<\/p>\n

    \n

    \ud83d\udca1 Intuition<\/strong> Une classe, c’est un plan de fabrication ; chaque objet cr\u00e9\u00e9 \u00e0 partir de ce plan emporte ses propres donn\u00e9es avec lui, et conna\u00eet les op\u00e9rations qui s’y appliquent.<\/p>\n<\/blockquote>\n

    Sous le capot : les briques d’une classe<\/h2>\n

    Une classe, un constructeur, un attribut<\/h3>\n

    Voici la classe la plus simple qui soit : elle a un constructeur __init__()<\/code> qui pose un attribut x<\/code>, et une m\u00e9thode qui l’affiche.<\/p>\n

    #!\/usr\/bin\/env python\n\nclass MyClass:\n    def __init__(self):\n          self.x = 5\n\n    def main(self):\n          print('inside main')\n          print('x:',self.x)\n\nif __name__ == '__main__':\n    myClass = MyClass()\n    myClass.main()\n<\/code><\/pre>\n
    Le bloc if __name__ == '__main__':<\/code> est un idiome que tu croiseras partout : il n’ex\u00e9cute son contenu que si le fichier est lanc\u00e9 directement, jamais lorsqu’il est simplement import\u00e9 par un autre programme. Trois fa\u00e7ons d’\u00e9crire l’en-t\u00eate existent (class MyClass:<\/code>, class MyClass():<\/code> ou class MyClass(object):<\/code>), mais elles sont \u00e9quivalentes : en Python 3, toute classe h\u00e9rite implicitement de object<\/code>.<\/p>\n
    Ce qui appartient \u00e0 l’objet, ce qui appartient \u00e0 la classe<\/h3>\n
    Une distinction change tout : une variable d’instance<\/strong> est propre \u00e0 chaque objet, une variable de classe<\/strong> est partag\u00e9e par toutes les instances.<\/p>\n
    class Company:\n    # a shared class variable:\n    location = "USA"\n    def __init__(self, name):\n        # an instance variable:\n        self.name = name\n<\/code><\/pre>\n
    Ici, location<\/code> est identique pour toutes les entreprises cr\u00e9\u00e9es ; name<\/code>, lui, est d\u00e9fini \u00e0 la cr\u00e9ation et diff\u00e8re d’un objet \u00e0 l’autre.<\/p>\n
    Public, prot\u00e9g\u00e9, priv\u00e9 : une question de politesse<\/h3>\n
    En Python 3, tout est public par d\u00e9faut. Un tiret bas en pr\u00e9fixe (_variable<\/code>) signale une variable prot\u00e9g\u00e9e, r\u00e9serv\u00e9e \u00e0 la classe et \u00e0 ses sous-classes ; un double tiret bas (__variable<\/code>) signale une variable priv\u00e9e, r\u00e9serv\u00e9e \u00e0 la classe elle-m\u00eame. Mais rien n’emp\u00eache techniquement d’y acc\u00e9der de l’ext\u00e9rieur, contrairement \u00e0 Java o\u00f9 le compilateur l’interdit.<\/p>\n
    \n
    \u26a0\ufe0f Pi\u00e8ge<\/strong> Un attribut \u00ab priv\u00e9 \u00bb en Python n’est priv\u00e9 que par convention : c’est ton engagement d’\u00e9quipe qui le prot\u00e8ge, pas le langage.<\/p>\n<\/blockquote>\n
    Le voir tourner : ton premier objet utile<\/h2>\n
    Reprenons notre jeu \u00e0 deux joueurs. Observe comment les deux scores et les quatre op\u00e9rations vivent dans la m\u00eame classe, et comment le code appelant se contente de donner des ordres \u00e0 un objet.<\/p>\n
    class ScoreTracker:\n    def __init__(self, player1_initial=0,\nplayer2_initial=0):\n        self.player1 = player1_initial\n        self.player2 = player2_initial\n\n    def update_score(self, player_number,\nnew_points=None):\n        if player_number == 1:\n            self.player1 += (new_points or 1)\n        elif player_number == 2:\n            self.player2 += (new_points or 1)\n        else:\n            raise ValueError("Player number must be 1 or 2")\n\n    def reset_scores(self):\n        self.player1 = 0\n        self.player2 = 0\n\n    def display_scores(self, format_style="{} - {}"):\n        return format_style.format(self.player1, self.player2)\n\n    def get_winner(self):\n        if self.player1 > self.player2:\n            return "Player 1"\n        elif self.player2 > self.player1:\n            return "Player 2"\n        else:\n            return "Tie"\n\n# Example usage\nscore_game = ScoreTracker()\nscore_game.update_score(1)\nscore_game.update_score(2, new_points=5) # Player 2 scores additional points\n\nprint(score_game.display_scores())\nprint("Current score:", score_game.player1, "-",\nscore_game.player2)\n\nif score_game.get_winner():\n    print(f"Winner is {score_game.get_winner()}!")\n\nscore_game.reset_scores()\nprint("Reset scores:", score_game.display_scores())\n<\/code><\/pre>\n
    Trois choses \u00e0 retenir de cet exemple. Les scores sont cr\u00e9\u00e9s une fois, dans le constructeur, avec 0 par d\u00e9faut. Chaque m\u00e9thode travaille sur ces m\u00eames scores sans qu’on ait \u00e0 les lui repasser. Enfin, l’appel update_score(2, new_points=5)<\/code> montre qu’une m\u00e9thode se r\u00e8gle avec des arguments, exactement comme une fonction : ta culture des fonctions reste donc enti\u00e8rement valable.<\/p>\n
    Cacher le \u00ab comment \u00bb derri\u00e8re un \u00ab quoi \u00bb<\/h3>\n
    Une classe peut aussi masquer sa cuisine interne. Ici, le code appelant ne conna\u00eet que search_list()<\/code> ; le choix entre une recherche lin\u00e9aire et une recherche binaire se fait \u00e0 l’int\u00e9rieur, dans des m\u00e9thodes pr\u00e9fix\u00e9es par __<\/code>.<\/p>\n
    class MyEncapsulation:\n   def __init__(self,my_list):\n     self.my_list = my_list\n     self.sorted = False\n\n   # invokes a private method:\n   def search_list(self,item):\n     self.__search_my_list(item)\n\n   def __search_my_list(self,item):\n     if(self.sorted == False):\n        # perform a linear search:\n        self.__linear_search(item)\n     else:\n        # perform a binary search:\n        self.__binary_search(item)\n\n   def __linear_search(self,item):\n     # perform a linear search\n     pass\n\n   def __binary_search(self,item):\n     # perform a binary search\n     pass\n\nif __name__ == '__main__':\n    enc1 = MyEncapsulation([4,1,5,3,8])\n    enc1.search_list(5)\n<\/code><\/pre>\n
    Le b\u00e9n\u00e9fice est concret : demain, on peut remplacer la recherche lin\u00e9aire par une binaire, ou l’inverse, sans changer la signature publique search_list()<\/code> ni le code qui l’appelle. On appelle cela l’encapsulation<\/strong> : faire \u00e9voluer l’int\u00e9rieur d’une classe sans casser ce qui en d\u00e9pend.<\/p>\n
    Faire parler tes objets avec les m\u00e9thodes magiques<\/h2>\n
    Les m\u00e9thodes dont le nom commence et finit par deux tirets bas (__add__()<\/code>, __len__()<\/code>, __str__()<\/code>\u2026) s’appellent des m\u00e9thodes magiques<\/strong>, ou dunders<\/em>. Elles permettent \u00e0 une classe personnalis\u00e9e de r\u00e9pondre aux op\u00e9rateurs standards de Python.<\/p>\n
    Deux d’entre elles d\u00e9cident de l’affichage : __str__()<\/code> vise un texte lisible pour l’utilisateur final, __repr__()<\/code> un texte utile au d\u00e9veloppeur. Si l’une manque, Python retombe sur l’autre, et print()<\/code> appelle __str__()<\/code> par d\u00e9faut.<\/p>\n
    Autre exemple : pour dire ce que signifie \u00ab inf\u00e9rieur \u00e0 \u00bb entre deux points en 3D, on \u00e9crit __lt__()<\/code>. On peut ensuite comparer deux objets avec l’op\u00e9rateur <<\/code>, comme n’importe quel type natif.<\/p>\n
    def __lt__(self, other):\n    if self.x < other.x and self.y < other.y and self.z < other.z:\n        return True\n    else:\n        return False\n\nif(p1 < p2): print("p1 < p2")\nelif (p2 < p1): print("p2 < p1")\nelse: print("cannot be compared")\n<\/code><\/pre>\n
    Ce m\u00eame __lt__()<\/code> est ce qu’utilise queue.PriorityQueue<\/code> pour savoir quelle t\u00e2che traiter en premier : elle compare les t\u00e2ches entre elles, et les traite par priorit\u00e9 croissante, quel que soit leur ordre d’insertion. Tes classes deviennent ainsi compatibles avec les outils de la biblioth\u00e8que standard.<\/p>\n
    \n
    \ud83d\udca1 Intuition<\/strong> Une m\u00e9thode magique, c’est un contrat : \u00ab si tu me fournis cette m\u00e9thode, Python saura s’en servir dans ses op\u00e9rateurs et ses boucles \u00bb.<\/p>\n<\/blockquote>\n
    Une classe qui se laisse parcourir<\/h3>\n
    Le m\u00eame principe s’applique aux boucles for<\/code>. Un objet est it\u00e9rable<\/strong> d\u00e8s qu’il d\u00e9finit __iter__()<\/code>, qui doit renvoyer un it\u00e9rateur, c’est-\u00e0-dire un objet dot\u00e9 de __next__()<\/code>, charg\u00e9 de produire l’\u00e9l\u00e9ment suivant ou de lever StopIteration<\/code> quand tout est \u00e9puis\u00e9.<\/p>\n\n\n
    \"Le\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
    Sur le sch\u00e9ma, suis les fl\u00e8ches de gauche \u00e0 droite : 
    iter(obj)<\/code> d\u00e9clenche __iter__()<\/code>, qui renvoie un it\u00e9rateur, puis la boucle for<\/code> r\u00e9clame chaque \u00e9l\u00e9ment avec __next__()<\/code> jusqu’\u00e0 l’exception finale.<\/figcaption><\/figure>\n\n\n
    R\u00e9utiliser sans copier : h\u00e9ritage et polymorphisme<\/h2>\n
    L’h\u00e9ritage : \u00ab fais comme ma classe parente \u00bb<\/h3>\n
    Quand une classe B<\/code> h\u00e9rite d’une classe A<\/code>, tout ce que A<\/code> d\u00e9finit devient accessible depuis B<\/code>. Dans l’exemple ci-dessous, la m\u00e9thode func()<\/code> de MyClassB<\/code> est mise en commentaire : c’est donc celle de MyClassA<\/code> qui s’ex\u00e9cute quand on appelle instanceB.func()<\/code>.<\/p>\n
    class MyClassA:\n   def __init__(self):\n      print('Hello from A')\n\n   def func(self):\n      print('Hello again from A')\n\nclass MyClassB(MyClassA):\n   def __init__(self):\n      print('Hello from B')\n\n  #def func(self):\n  # print('Hello again from B')\n\nif __name__ == '__main__':\n    instanceA = MyClassA()\n    instanceB = MyClassB()\n\n    print()\n    print('instanceA:')\n    instanceA.func()\n    print('instanceB:')\n    instanceB.func()\n<\/code><\/pre>\n\n\n
    \"H\u00e9ritage\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
    Regarde la fl\u00e8che \u00ab h\u00e9ritage \u00bb du sch\u00e9ma : tant que 
    MyClassB<\/code> ne red\u00e9finit pas func()<\/code>, Python remonte vers la classe parente pour la trouver.<\/figcaption><\/figure>\n\n\n
    Un contrat pour les sous-classes<\/h3>\n
    Une classe de base peut aussi servir de simple contrat<\/strong>. Dans un exemple de pr\u00e9f\u00e9rences alimentaires, la classe parente MyFoodPrefs<\/code> l\u00e8ve volontairement NotImplementedError<\/code> dans chacune de ses m\u00e9thodes : elle impose aux sous-classes MyVegetarian<\/code> et MyCarnivore<\/code> d’\u00e9crire leur propre version. Chacune appelle super().__init__()<\/code> pour d\u00e9clencher le constructeur de la classe parente. La version v\u00e9g\u00e9tarienne refuse d’ajouter \u00ab Steak \u00bb ou \u00ab Chicken \u00bb, la version carnivore n’applique jamais ce filtre.<\/p>\n
    Le polymorphisme : une fonction, plusieurs classes<\/h3>\n
    C’est ici que tes fonctions retrouvent leur place. Le polymorphisme<\/strong> d\u00e9signe la capacit\u00e9 d’une m\u00eame fonction \u00e0 op\u00e9rer sur des objets de classes diff\u00e9rentes, pourvu qu’ils exposent l’interface attendue. Regarde calcPerimeter()<\/code> : elle ne teste jamais le type de son argument.<\/p>\n
    class MyRect:\n   def perimeter(self):\n     print('Perimeter of a rectangle')\n\nclass MySquare:\n   def perimeter(self):\n     print('Perimeter of a square')\n\ndef calcPerimeter(obj):\n     obj.perimeter()\n\nif __name__ == '__main__':\n    instanceR = MyRect()\n    instanceS = MySquare()\n\n    print('instanceR:')\n    calcPerimeter(instanceR)\n    print('instanceS:')\n    calcPerimeter(instanceS)\n<\/code><\/pre>\n
    MyRect<\/code> et MySquare<\/code> n’ont aucun lien de parent\u00e9 : seul compte le fait que les deux exposent une m\u00e9thode perimeter()<\/code>. C’est le duck typing<\/strong> : la fonction ne se soucie pas de la classe exacte, seulement de savoir si l’objet \u00ab se comporte comme un canard \u00bb. Java exigerait une interface commune ; en Python, cette exigence reste implicite. Pour formaliser malgr\u00e9 tout le contrat, le module abc<\/code> (Abstract Base Class) permet de d\u00e9finir des classes abstraites qui imposent les m\u00e9thodes \u00e0 impl\u00e9menter.<\/p>\n
    \n
    \ud83d\udccc \u00c0 retenir<\/strong> Passer aux objets ne t’oblige pas \u00e0 jeter tes fonctions : une fonction qui accepte \u00ab n’importe quel objet sachant faire ceci \u00bb est l’une des formes les plus \u00e9l\u00e9gantes du polymorphisme.<\/p>\n<\/blockquote>\n
    Pi\u00e8ges et limites<\/h2>\n
      \n
    • \n
      Constructeurs jamais appel\u00e9s.<\/strong> Dans l’exemple d’h\u00e9ritage multiple, MyClassC(MyClassA, MyClassB)<\/code> d\u00e9finit son propre __init__()<\/code> sans appeler ceux de ses parents : ils ne s’ex\u00e9cutent donc pas. Pense \u00e0 super().__init__()<\/code> quand tu veux le comportement du parent.<\/p>\n<\/li>\n
    • \n
      H\u00e9ritage multiple : l’ordre compte.<\/strong> Quand deux parents d\u00e9finissent la m\u00eame m\u00e9thode, Python la cherche de gauche \u00e0 droite dans la liste des parents. Avec MyClassC(MyClassA, MyClassB)<\/code>, c’est celle de MyClassA<\/code> qui gagne ; inverse l’ordre et le r\u00e9sultat bascule. Le module inspect<\/code> te montre cet ordre de r\u00e9solution (le MRO) avec inspect.getmro(MaClasse)<\/code>.<\/p>\n<\/li>\n
    • \n
      Toujours passer par iter()<\/code>.<\/strong> Appeler directement __iter__()<\/code> ne d\u00e9clenche aucune v\u00e9rification, alors que la fonction iter()<\/code> l\u00e8ve une TypeError<\/code> si __iter__()<\/code> ne renvoie pas un vrai it\u00e9rateur.<\/p>\n<\/li>\n
    • \n
      L’addition n’est pas sym\u00e9trique.<\/strong> myobj1 + 7<\/code> fonctionne gr\u00e2ce \u00e0 __add__()<\/code>, mais 7 + myobj1<\/code> \u00e9choue tant que tu n’as pas \u00e9crit __radd__()<\/code>. M\u00eame principe pour __sub__()<\/code>\/__rsub__()<\/code> et __mul__()<\/code>\/__rmul__()<\/code>.<\/p>\n<\/li>\n
    • \n
      Ne compte pas sur __del__()<\/code>.<\/strong> Son ex\u00e9cution n’est pas garantie : pour lib\u00e9rer un fichier ou une connexion, ferme-les explicitement.<\/p>\n<\/li>\n<\/ul>\n\n\n
      \"H\u00e9ritage\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
      Sur ce sch\u00e9ma, la recherche s’arr\u00eate \u00e0 la premi\u00e8re classe, en partant de la gauche, qui d\u00e9finit vraiment la m\u00e9thode demand\u00e9e : ici 
      A2<\/code>.<\/figcaption><\/figure>\n\n\n
      Aller plus loin<\/h2>\n
        \n
      • __init__<\/code> et sa fratrie<\/strong> : trois m\u00e9thodes encadrent la vie d’un objet \u2014 __new__()<\/code> le cr\u00e9e, __init__()<\/code> l’initialise, __del__()<\/code> intervient \u00e0 sa destruction.<\/li>\n
      • Le protocole d’it\u00e9ration<\/strong> : c’est le m\u00e9canisme qui se cache derri\u00e8re toute boucle for<\/code>, et que ta classe peut impl\u00e9menter \u00e0 son tour.<\/li>\n
      • Les collections d’objets<\/strong> : une classe qui encapsule une liste d’objets \u00ab valeur \u00bb (des employ\u00e9s, par exemple) est un motif que l’on retrouve dans la plupart des applications r\u00e9elles.<\/li>\n
      • Tes propres structures de donn\u00e9es<\/strong> : liste cha\u00een\u00e9e, file de priorit\u00e9\u2026 rien n’emp\u00eache de les construire avec des classes personnalis\u00e9es.<\/li>\n<\/ul>\n
        \u00c0 retenir<\/h2>\n
          \n
        • Une classe range au m\u00eame endroit un \u00e9tat et les op\u00e9rations qui le modifient : tu donnes des ordres \u00e0 un objet au lieu de faire circuler des variables.<\/li>\n
        • Ce que tu sais des fonctions (arguments, valeurs par d\u00e9faut, retours) s’applique tel quel aux m\u00e9thodes.<\/li>\n
        • Les m\u00e9thodes magiques rendent tes objets compatibles avec les op\u00e9rateurs, les comparaisons et les boucles de Python.<\/li>\n
        • L’h\u00e9ritage r\u00e9utilise une classe ; le duck typing permet de ne pas en avoir besoin quand seule l’interface compte.<\/li>\n
        • Python te fait confiance : priv\u00e9 et prot\u00e9g\u00e9 sont des conventions, pas des barri\u00e8res.<\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"
          Tes scripts Python ne sont faits que de fonctions ? D\u00e9couvre comment passer \u00e0 la programmation orient\u00e9e objet : classes, m\u00e9thodes, h\u00e9ritage, polymorphisme.<\/p>\n","protected":false},"author":1,"featured_media":267,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-138","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-python"],"_links":{"self":[{"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/posts\/138","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/comments?post=138"}],"version-history":[{"count":2,"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/posts\/138\/revisions"}],"predecessor-version":[{"id":140,"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/posts\/138\/revisions\/140"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/media\/267"}],"wp:attachment":[{"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/media?parent=138"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/categories?post=138"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/tags?post=138"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}