Discussion :

[ptrs32]

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 :

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
 
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

[papajoker]

bonjour

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

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

[ptrs32]

bonjour

pas assez de détail pour bien répondre, mais l'héritage sert justement à cela
"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 ?

[Aiveriwhair]

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.

[papajoker]

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.

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.

[Sve@r]

Bonjour

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

Comment fonctionnerait l'héritage exactement ?

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
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)...

[ptrs32]

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.

... 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.

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

[Aiveriwhair]

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.

[Sve@r]

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.

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é.

[Invité]

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.

[Sve@r]

C'est donc à ça que sert super !

Pas que.

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

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
# 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 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
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 python :

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

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 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
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 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
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)

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

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

Code python :

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

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 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
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...

[Invité]

Gracias !

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.

[Sve@r]

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 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
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...)

[papajoker]

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

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

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é

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

[Invité]

En effet, on est bien mieux sans la poo

Ah ben voilà quelqu'un qui me comprend !