Utiliser la même fonction dans différentes Class

Bonjour à tous,

Comme le dit le titre, j'ai une propriété de classe que je souhaite dupliquer dans plusieurs autres et je ne trouve pas de façons de le faire.

Pour être plus clair j'ai ce genre de script:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

class premiereClasse(): #contenu   def functionUniverselle(self): #contenu de la fonction   class secondeClasse(): #contenu   def functionUniverselle(self): #contenu de la fonction   class troisiemeClasse(): #contenu   def functionUniverselle(self): #contenu de la fonction

---

Je souhaiterais n'avoir à écrire ma fonctionUniverselle(self) qu'une seule fois et ensuite l'appeler simplement dans chaque classe nécessaire.

Est-ce possible ?
Merci d'avance

bonjour

pas assez de détail pour bien répondre, mais l'héritage sert justement à cela :oops:
"premiereClasse" pourrait être une classe abstraite ?

ps: existe aussi les méthodes de classes (utile ici ?)

Citation:

---

Envoyé par papajoker

bonjour

pas assez de détail pour bien répondre, mais l'héritage sert justement à cela :oops:
"premiereClasse" pourrait être une classe abstraite ?

---

Merci pour la réponse,

Je n'ai pas de classe abstraite, ce sont des classes python tout à fait classiques si je peux dire.
Comment fonctionnerait l'héritage exactement ?

Tu aurais tout simplement une classe mère de "premiereClasse", "deuxiemeClasse" et "troisiemeClasse" qui définirait la fonction que tu souhaites retrouver dans tes trois classes. De cette manière, toutes tes classes partageraient la même fonction définie dans la classe mère. C'est la base de la POO, tu trouveras tout ce qu'il te faut en quelques minutes de recherche sur notre cher internet au sujet de l'héritage.

Citation:

---

Envoyé par ptrs32

Je n'ai pas de classe abstraite, ce sont des classes python tout à fait classiques si je peux dire.

---

D'où mon point d'interrogation, tu utilises ou non des classes abstraites, tout dépend de ton besoin/architecture. Utiliser l'héritage est justement une chose classique.

Citation:

---

Envoyé par ptrs32

Comment fonctionnerait l'héritage exactement ?

---

pas compris la question , tu n'as jamais lu un tuto python sur l'objet ? l'héritage est une chose plus que classique et que le "parent" soit abstrait ou non ne change strictement rien.

une classe abstraite signifie uniquement que c'est une classe que nous n'utiliserons jamais directement, elle ne sert que pour l'héritage, elle n'existe que pour partager une fonctionnalité entre plusieurs classes.

Bonjour

Citation:

---

Envoyé par ptrs32

Je n'ai pas de classe abstraite, ce sont des classes python tout à fait classiques si je peux dire.

---

Hum... un certain manque flagrant de connaissances POO... C'est pas grave, on n'en a pas besoin ici

Citation:

---

Envoyé par ptrs32

Comment fonctionnerait l'héritage exactement ?

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

# Classe de base class premiereClasse(): # Constructeur première classe def __init__(self, ...) # contenu   def functionUniverselle(self): # contenu de la fonction   # Seconde classe qui hérite de la première (elle récupère toutes ses propriétés et méthodes) mais sert à faire des trucs en plus class secondeClasse(premiereClasse): # Constructeur seconde classe def __init__(self, ...) # On commence par appeler le constructeur de la classe dont on hérite (certains langages tels le C++ le font automatiquement, pas Python) super().__init__(self, ...) # contenu de ce qui est fait en plus   # Pas besoin de fonction universelle si elle ne fait rien de plus, on en hérite automatiquement (c'est ça l'héritage)   # Troisième classe qui hérite de la seconde (elle récupère toutes ses propriétés et méthodes) et sert là encore à faire des trucs en plus class troisiemeClasse(secondeClasse): # Constructeur troisième classe def __init__(self, ...) # On commence par appeler le constructeur de la classe dont on hérite super().__init__(self, ...) # contenu de ce qui est fait en plus   # La fonction universelle (qui fera comme celle dont on hérite mais avec des trucs en plus) def functionUniverselle(self): # On commence par appeler la fonction universelle dont on hérite super().functionUniverselle(self) # contenu de la suite de cette fonction plus particulière   base=premiereClasse(...) base.functionUniverselle() # Appel fonction universelle première classe   second=secondeClasse(...) second.functionUniverselle() # Appel fonction universelle seconde classe (qui est donc celle de la première puisque la seconde classe en hérite et n'en a pas définie d'autre)   third=troisiemeClasse(...) third.functionUniverselle() # Appel fonction universelle troisième classe (qui fera le travail de la seconde (ie de la première donc) plus ses trucs à elle)

---

Ou alors la fonction universelle n'est pas associée à une classe et devient une vraie fonction indépendante, qui pourra donc être appelée depuis (ou plutôt "avec") n'importe quel objet (et dans ce cas, plus besoin ni d'héritage ni même d'objet)...

Citation:

---

Envoyé par Aiveriwhair

C'est la base de la POO, tu trouveras tout ce qu'il te faut en quelques minutes de recherche sur notre cher internet au sujet de l'héritage.

---

Citation:

---

Envoyé par papajoker

... tu n'as jamais lu un tuto python sur l'objet ? l'héritage est une chose plus que classique et que le "parent" soit abstrait ou non ne change strictement rien.

---

Citation:

---

Envoyé par Sve@r

Bonjour

Hum... un certain manque flagrant de connaissances POO... C'est pas grave, on n'en a pas besoin ici

---

C'est drôle comme vous les "séniors" en programmation sur les forums vous adorez le passif-agressif quand vous répondez à des débutants. Une façon de montrer votre supériorité, ou un peu de sadisme sous-jacent qui sait ? Ça m'étonne toujours puisque logiquement si la question vous énerve autant laissez quelqu'un d'autre y répondre. Enfin bon..

Je vous remercie pour vos réponses qui ne me font pas du tout regretter de l'avoir poser ici et me réconfortent dans mes compétences en Python.

Je vais donc faire une classe abstraite avec mes fonctions récurrentes et gérer l'héritage dans les différentes classes.

Bonne journée

Premièrement je ne vois pas le passif-agressif dans ma réponse mais passons. Je pense que ton message a donné l'impression que tu n'as pas fait la moindre recherche avant de poser ta question sur le forum et ce n'est pas vraiment l'esprit des forums info. C'est d'ailleurs pour cela que je t'ai donné une piste et pas du code prémâché ! Si, contrairement à ce que ton message laissait penser tu as bel et bien chercher une solution a ton problème avant de poster, je suis désolé pour mon ton "passif-agressif".

Belle fin de journée.

Citation:

---

Envoyé par ptrs32

C'est drôle comme vous les "séniors" en programmation sur les forums vous adorez le passif-agressif quand vous répondez à des débutants.

---

Tu n'y es pas. Ce n'est pas ton état de débutant qui est en cause (on l'a tous été), c'est le fait que tu n'aies pas fait l'effort préalable de lire un tutoriel, préférant recevoir l'information toute cuite dans le bec plutôt que d'y arriver naturellement quand tu arrives à ce chapitre en ayant donc lu (et généralement assimilé) les précédents.

Citation:

---

Envoyé par ptrs32

Une façon de montrer votre supériorité, ou un peu de sadisme sous-jacent qui sait ?

---

Balade-toi dans le forum (ici ou d'autres), tu verras que les débutants qui montrent qu'ils ont fait un certain effort préalable avant de venir poser leur question sont traités différemment...

Toutefois de mon côté, je remarque que généralement, les débutants qui s'offusquent de cet accueil (mérité) sont généralement les plus instruits. Toi tu es ingénieur d'études cliniques, mais on a eu d'autres ingénieurs en tout genre, généralement tous aussi vexés qu'on leur dise que Python, comme tout le reste, ça commence par s'apprendre. C'est peut-être aussi une façon (plus subtile) de montrer leur supériorité en sous-entendant implicitement que la programmation en général (ou alors juste Python en particulier) n'est pas digne de leur niveau, sous-domaine tellement peanut qu'on peut l'assimiler par capilarité.

C'est donc à ça que sert super !
^^

Toujours pas trouvé d'intérêt à coder en POO (sauf de façon anecdotique) après 15 ans de bidouillage pythonesque. :haha:

Citation:

---

Envoyé par LeNarvalo

C'est donc à ça que sert super !

---

Pas que.

A la base tu peux très bien faire sans...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

# Classe de base class premiereClasse(): # Constructeur première classe def __init__(self, ...) # contenu   # Seconde classe qui hérite de la première (elle récupère toutes ses propriétés et méthodes) mais sert à faire des trucs en plus class secondeClasse(premiereClasse): # Constructeur seconde classe def __init__(self, ...) # On commence par appeler le constructeur de la classe dont on hérite premiereClasse.__init__(self, ...)   # contenu de ce qui est fait en plus

---

Le souci arrive quand tu as un héritage type diamant (une classe A, deux classes B et C qui héritent de A et une 4° classe D qui hérite de B et C).

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

class A: def __init__(self): print("A.init")   class B(A): def __init__(self): print("B.init") A.__init__(self)   class C(A): def __init__(self): print("C.init") A.__init__(self)   class D(B, C): def __init__(self): print("D.init") B.__init__(self) C.__init__(self)

---

Et là tu vois avec horreur qu'instancier D entraine deux appels à l'init de A

Code:

---

1 2 3 4 5 6

>>> D() D.init B.init A.init C.init A.init

---

super() passe par le MRO (Method Resolution Order) qui est un truc intelligent qui, voyant que A est déjà instancié, ne le réinstancie pas une seconde fois

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

class A: def __init__(self): print("A.init")   class B(A): def __init__(self): print("B.init") super(B, self).__init__()   class C(A): def __init__(self): print("C.init") super(C, self).__init__()   class D(B, C): def __init__(self): print("D.init") super(D, self).__init__()   >>> D() D.init B.init C.init A.init

---

(accessoirement je l'ai écrit ici à la forme P2 qui demande d'expliciter le nom de la classe d'appel pour que tu voies le cheminement mais, petit bonus, ça a été simplifié sous P3)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

class A: def __init__(self): print("A.init")   class B(A): def __init__(self): print("B.init") super().__init__()   class C(A): def __init__(self): print("C.init") super().__init__()   class D(B, C): def __init__(self): print("D.init") super().__init__()   >>> D() D.init B.init C.init A.init

---

Bien entendu, ça n'est réellement utile que si tu fais de l'héritage multiple mais puisque ça fonctionne aussi en héritage simple, il n'y a aucune raison de s'en priver (syntaxe simple et fluide, si le nom de l'objet ou de son parent change, pas besoin de checker le reste du code, c'est Python qui s'y colle)

Citation:

---

Envoyé par LeNarvalo

Toujours pas trouvé d'intérêt à coder en POO (sauf de façon anecdotique) après 15 ans de bidouillage pythonesque. :haha:

---

Perso je trouve que ça simplifie vachement les choses
Sans POO

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

# Première difficulté: trouver des fonctions au nom parlant def surface_carre(c): return c**2 def surface_cercle(r): return r**2 * 3.14   # Seconde difficulté: trouver des variables au nom parlant cote_carre=5 rayon_cercle=7   # Troisième difficulté: éviter de se tromper de cible... print(surface_carre(cote_carre)) print(surface_cercle(rayon_cercle)) print(surface_cercle(cote_carre)) # Oups...

---

Avec POO

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

# Seule difficulté: trouver le nom de ses classes. Perso je les fais précéder de "c" (classe) class cCarre: def __init__(self, c): self.c=c def surface(self): return self.c**2   class cCercle: def __init__(self, r): self.r=r def surface(self): return self.r**2 * 3.14   # Pour les variables, c'est simplex carre=cCarre(5) cercle=cCercle(7)   # Ensuite, ça roule print(carre.surface()) print(cercle.surface())   # Peut-on se tromper de cible ? On peut le tenter mais déjà faut vraiment vraiment le faire vraiment exprès... print(cCercle.surface(carre)) # ... et même comme ça (chance, ça plante parce que les noms des attributs diffèrent entre les deux objets) #Traceback (most recent call last): # File "....py", line 19, in <module> # print(cCercle.surface(carre)) # File "....py", line 8, in surface # def surface(self): return self.r**2 * 3.14 #AttributeError: 'cCarre' object has no attribute 'r'

---

Après c'est aussi une question de motivation. Mais passer un truc "fonctionnel" en truc "poo" c'est moins difficile que ce qu'on imagine...

Gracias ! :ccool:

Il me semble que tu m'avais déjà donné l'exemple avec le carré et le cercle ! ^^

Les rares fois où je fais un peu de POO c'est pour mes tentatives de création de jeux-vidéo avec une classe Player qui stocke des variables et c'est tout, un peu plus esthétique qu'un dictionnaire en somme.

Citation:

---

Envoyé par LeNarvalo

Les rares fois où je fais un peu de POO c'est pour mes tentatives de création de jeux-vidéo avec une classe Player qui stocke des variables et c'est tout

---

C'est un bon début. ensuite tu rajoutes une classe "terrain" (parce que fatalement le player il doit évoluer quelque part) voire une classe "jeu". Si le player doit se déplacer tu lui rajoutes une méthode "deplace()". Imaginons qu'il y ait deux joueurs, il pourra(it) y avoir collision donc il faudra une fonction qui détecte cette collision. Cette fonction étant plus ou moins "générale" (ne s'applique pas à un joueur en particulier) mais concernant quand-même la catégorie player pourra alors être statique à la classe player

De fait

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

class cJeu: def __init__(self, longueur, largeur): self.terrain=... self.joueurs=tuple(cPlayer() for i in range 2) # __init__()   def run(): ... # class cJeu   class cPlayer:         @staticmethod def isCollision(p1, p2): return p1.coordonnees in p2.coordonnees or p2.coordonness in p1.coordonnees   def __init__(self): self.coordonnes=...   def move(self, direction): ... # class cPlayer   # Jeu jeu().run()

---

Bon c'est un truc grossier qui montre l'idée. En POO tu prends du temps pour faire les bases, c'est à la fin que tu obtiens le bénéfice de ton travail (ici un simple jeu().run() qui fait tout le job). Tandis qu'en programmation fonctionnelle c'est le contraire (les bases sont légères et généralement faciles à faire, l'assemblage se fait à la fin et c'est là qu'on galère).

Si tu as PyQt, tu peux tenter d'aller télécharger ce petit tutoriel. A la base il est fait pour montrer PyQt mais il est fait façon POO (un objet "canon", un objet "champ de tir" etc...)

Citation:

---

Envoyé par LeNarvalo

Toujours pas trouvé d'intérêt à coder en POO

---

Imagine simplement un python sans objet :roll:
pas de str.truc pas de list.machin ... En effet, on est bien mieux sans la poo :ptdr:

Citation:

---

Envoyé par ptrs32

avoir poser ici et me réconfortent dans mes compétences en Python.

---

Donc si je comprends bien, ici le problème est en fait une question d'égo. Être humble est une qualité ;)

Citation:

---

Envoyé par ptrs32

Je vais donc faire une classe abstraite avec mes fonctions récurrentes et gérer l'héritage dans les différentes classes.

---

Donc en fait le message n'est pas passé :(
Nous n'avons eu aucune information pertinente pour donner une bonne réponse ! Si tu ne connaissais pas l'héritage, comment as-tu pu créer des classes ? Rien ne nous dit que l'héritage (surtout avec classe abstraite) soit une bonne solution (par exemple existe aussi la composition) :
1) on apprend
2) on fait notre structure, notre code
j'ai l'impression (puisque débutant) que tu demandes un pansement sur ton code (mais en ne donnant aucun symptôme)

Ici, apparemment, tu codes déjà alors que tu n'as pas les bases ... je ne peux que me répéter, avant de coder, il faut apprendre un minimum (rien de déshonorant à cela, nous l'avons tous fait car "nous", nous ne sommes pas sortis de la cuisse de Jupiter)
Si je codais des classes maladies à la suite (ebola .. grippe ... diabète), tu me prendrais de haut !
je suppose que les classes seraient plus (virus -> ebola, gripe - hereditaire -> truc, machin - ... ) Clair qu'ici, je n'ai pas besoin de classe abstraite puisque j'ai dès le départ une bonne structure

Citation:

---

Envoyé par papounetjoker

En effet, on est bien mieux sans la poo

---

Ah ben voilà quelqu'un qui me comprend ! ;)