C'est exactement ce que @josmiley propose, comme on a pas de réponse, je donne un exemple,
class dad:
def __init__(self):
self._x = None
@property
def x(self):
return self._x
@x.setter
def x(self, value):
self._x = value
class son(dad):
@dad.x.setter
def x(self, value):
if value is not None:
print("Son: x cannot be modified")
s = son()
s.x = 'unknow value'
- Edité par fred1599 17 janvier 2023 à 23:42:30
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard) La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
class Papa:
def __init__(self):
if type(self) == Papa:
self.x = 5
else:
object.__setattr__(self,"x",None)
def __setattr__(self,attr,value):
if attr == "x" and type(self) != Papa:
print ("non! faut pas toucher à x")
else:
object.__setattr__(self,attr,value)
class Fils(Papa):
def __init__(self):
Papa.__init__(self)
p = Papa()
p.x = 9
print ("x de Papa : ",p.x)
a = Fils()
print ("x de Fils :",a.x)
a.x = 3
print ("x de Fils vaut toujours :",a.x)
C'est pour le fond, car pour la forme c'est beaucoup moins sexy
Ta ligne 18 et 19 ne servent à rien, tu peux les retirer je pense...
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard) La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
Je ne connais pas les @property python je vais aller lire la doc à son sujet.
Il semblerait que ce soit une solution fonctionnelle merci. Mais à premiers vu, j'ai l'impression que c'est plus un pansement d'un problème de conception.
Je n'ai pas encore de code à vous montrer, car pour l'instant je crée le diagramme de classe, et je réfléchie justement à la meilleur structure.
Mais merci beaucoup pour vos réponse.
edit: les property c'est cool effectivement,notamment si comme moi tu viens du C++/Java et que tu aime les getter et setter =)
C'est pour le fond, car pour la forme c'est beaucoup moins sexy
Ta ligne 18 et 19 ne servent à rien, tu peux les retirer je pense...
Ben ça sert si on veut ajouter ou modifier des attributs. Sinon effectivement tel quel ça sert à rien.
Moins sexy faut voir , syntaxiquement peut-être , maintenant on économise _x , on concentre tout dans la class Papa et on peut ajouter d'autres attributs à filtrer sans multiplier les property.
C'est pas le principe de l'héritage... Le principe est de modifier, ajouter certains attributs, certaines méthodes existantes ou non en héritant d'une classe Mère.
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard) La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
C'est pas le principe de l'héritage... Le principe est de modifier, ajouter certains attributs, certaines méthodes existantes ou non en héritant d'une classe Mère.
J'ai pas compris. Si Fils redéfinit __init__ et qu'il veut hériter des attributs Papa , il doit bien appeler Papa.__init__ à un moment non ?
Tu sais ce qu'est un héritage et à quoi ça sert... ce que tu as créé est un pseudo héritage, car c'est dans la classe Mère que tu prévois la création ou non d'une classe fille, un genre de métaclasse dans une classe. L'aspect dynamique c'est bien, mais il ne faut pas en abuser, on arrive vite à des choses difficiles à lire et surtout à maintenir.
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard) La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
Dans la classe Fils j'ai une fonction qui manipule mes attribues:
def manipulation(self,paramA):
if paramA.valeur > self.valeur :
if self.attribueA is None:
self.attribueA=paramA
else:
self.attribueA.manipulation(paramA)
Si j'utilise cette syntaxe (donc sans passer par self._attribueA), j'ai l'impression que python ne comprend pas que je fait référence à la variable de la classe Pere, et l'interperete donc comme un nouvelle attribue de ma classe fils.(et donc il chouine lorsque je fait self.attribueA.manipulatio(paramA) car il pense que attribueA est de type int (alors qu'il est du type obj papa).
Sauf que quand j'utilise self._attribueA, il ne passe pas non plus dans les getters/setter de la classe pére.
Il semble qu'il y ait un truc que je n'ai pas comprit avec les @property ou bien je me loupe dans la syntaxe (auquel cas qu'elle est la bonne syntaxe pour faire reference à un getter/setter de la classe papa).
Tu sais ce qu'est un héritage et à quoi ça sert... ce que tu as créé est un pseudo héritage, car c'est dans la classe Mère que tu prévois la création ou non d'une classe fille, un genre de métaclasse dans une classe. L'aspect dynamique c'est bien, mais il ne faut pas en abuser, on arrive vite à des choses difficiles à lire et surtout à maintenir.
Haaaa je vois , effectivement. Mais du coup , est-ce que Fils ne devrait s'interdire de modifier Papa.x sans devoir définir une propriété x dans Papa ?
Tu sais ce qu'est un héritage et à quoi ça sert... ce que tu as créé est un pseudo héritage, car c'est dans la classe Mère que tu prévois la création ou non d'une classe fille, un genre de métaclasse dans une classe. L'aspect dynamique c'est bien, mais il ne faut pas en abuser, on arrive vite à des choses difficiles à lire et surtout à maintenir.
Haaaa je vois , effectivement. Mais du coup , est-ce que Fils ne devrait s'interdire de modifier Papa.x sans devoir définir une propriété x dans Papa ?
Quand tu hérites, tu hérites de toute la classe Mère, y compris les attributs... Lorsque tu crées ton instance Fils, tu ne modifies pas les attributs de la classe Mère, mais juste les attributs de l'instance. En héritant de Papa, Fils reçoit ses attributs, tu auras un accès en lecture de l'attribut x, mais on ne souhaite pas pour les instances Fils un accès en écriture, tu dois donc surcharger le setter de ta classe Fils pour y indiquer ce que tu souhaites faire lors de l'écriture de l'attribut x. On est totalement dans l'intérêt de l'héritage, en indiquant que Père et Fils fonctionnent de la même manière, sauf en ce qui concerne l'écriture de x. J'ai mis un print (un pass quoi) plutôt qu'un raise, mais ça c'est une question de besoin sur l'arrêt préliminaire ou non du programme.
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard) La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
Conception d'objet
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Python c'est bon, mangez-en.
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
Python c'est bon, mangez-en.
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
Python c'est bon, mangez-en.
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
Python c'est bon, mangez-en.
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
Python c'est bon, mangez-en.
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)