Bonjour à tous.

Je me suis mis récemment au Python pour les nombreux avantages que cela me procure, possibilité de programmer à l'école sans risque de blocage, documentation complète, communauté plutôt développée et aussi le fait que c'est un langage orientée object (avec la philosophie qui suit)

Donc voila je comprend un peu le principe, l'encapsulation, la puissance de réutilisation du code qui en découle etc.

J'ai simplement une question qui me vient en tête juste après avoir penser à un projet potentiel, je vais donc donner un tout autre example plus générique pour éviter de perdre les lecteurs dans un cas trop spécifique lier à mon projet.

La question globale est : peut-on changer l'héritage d'une instance ?

Je m'explique, supposons une classe Personne avec comme attribut un age, une taille, un poids, un nom et des méthodes manger(), boire(), dormir) et j'en passe, tout ce qui est commun aux humains quoi.

On pourrait créer une classe qui hérite de Personne disons Mécanicien, avec cette classe nous avons maintenant de nouveaux attributs comme salaire, compétences, entreprise et une méthode reparerVoiture par exemple.

Mais voila qu'est-ce qui se passe si dans notre exemple notre Personne se fait virer de son emploi et se retrouve après coup chômeur ou bien même boulanger ? l'instance devra alors hériter d'une classe boulanger avec de nouvelle méthodes/attributs tout en restant le même humain.

Comment alors faire en sorte de changer l'héritage de façon dynamique ?

Bonsoir.

On ne peut pas changer l'héritage d'une instance. L'héritage concerne les classes et pas les objets.

C'est comme pour les personnes. Tout est cohérent.

Il ne faut pas utiliser d'héritage dans le cas que tu évoque.

Si il y a des changements il vaut mieux utiliser une relation cliente.

Ta classe Employé pourrait avoir un attribut "métier". Chaque métier serait alors symbolisé par un objet ...

-
Edité par Conaclos 25 février 2013 à 0:01:34

Arnaud TYMEN a écrit:

Bonsoir.

On ne peut pas changer l'héritage d'une instance. L'héritage concerne les classes et pas les objets.

C'est comme pour les personnes. Tout est cohérent.

Je m'en doutais mais j'arrive pas à imaginer d'autres solutions donc bon, qui c'est le seul qui me venait à l'esprit.

Pourrai-je avoir un code exemple de la relation cliente ? Ou un site sur lequel me tourner parce que là je vois pas trop comment mettre un attribut and tant qu'objet...

@soueuls

Non tu ne comprends pas... la phrase """comment mettre un attribut en tant qu'objet""" ne veut strictement rien dire.

Un attribut fait parti de l'objet, c'est une donnée qui renseigne sur l'objet.

Conceptuellement parlant, le métier est un attribut, aussi bien que âge, taille ou poids, c'est un renseignement sur la personne.

Maintenant tes méthodes sont différentes selon le métier et l'héritage semble tout à fait logique... Un mécanicien ou un boulanger est une personne.

Seulement ce n'est pas le plus simple dans le sens "maintenable".

La façon de faire suivante semble bien fonctionner, manque plus qu'à ajouter une méthode modifier_metier dans la classe Personne pour changer de métier comme tu le souhaites.

Un exemple:

class Personne:
    def __init__(self, nom, travail):
        self.nom = nom
        self.travail = travail
    def __str__(self):
        return "{0} est {1}".format(self.nom, self.travail.metier)

class Boulanger:
    def __init__(self):
        self.metier = "Boulanger"

boul1 = Boulanger()

Fred = Personne("Fred", boul1)
print(Fred) # "Fred est boulanger"

Autre chose, une instance n'hérite pas, tu as sans doute pas mal de choses en POO pas encore au point.

Une instance est créée par l'intermédiaire d'une classe, je dis souvent que l'instance est l'objet et la classe est le patron de l'objet.

On peut donc construire par le biais de cette classe autant d'objets que l'on souhaite.

@Arnaud TYMEN

Les classes concernent aussi les objets, sachant que sans elles (les classes), tu ne peux pas les fabriquer

+1 pour Conaclos, je pense qu'on est sur la même longueur d'ondes.

En gros, vous venez de décrire le pattern Strategy.

Plutôt que de dire qu'un Boulanger ou un Mécanicien EST UNE Personne, on dit qu'une Personne A UN Métier.

Ça évite de dériver plein de fois de la classe Personne, et ça permet à une Personne de changer dynamiquement de métier pendant l'éxécution.

-
Edité par nohar 25 février 2013 à 10:56:44

J'avais bien compris le concept d'une instance, et je voyais bien le fait qu'on pouvais pas changer l'heritage d'une instance, simplement je voyais pas de solution autre donc bon je me suis dit, on sait jamais, je vais en parler et donner un exemple concret de ce que je veux on pourra surement me diriger.

Je suis par contre pas bien sur de comprendre le code donne en exemple, enfin je le comprend mais ce que je ne comprend pas c'est plutot comment se deroulerais les methodes et/ou attributs propres aux personnes qui sont boulanger/mecanicien etc... Ou alors on se retrouve avec une classe plutot longue suivant le cas.

Pour faire simple, le métier de boulanger ou mécanicien se retrouve en tant qu'attribut de la classe Personne.

Comme dis nohar, la personne à le métier de mécanicien, plutôt que de dire, le mécanicien est une personne.

L'avantage de bien séparer les classes, c'est :

• s'y retrouver dans son code
• modifier, supprimer, ... dans la classe concernée à ta guise
• rendre ton code maintenable
• éviter les redondances

Maintenant sur le net tu peux à l'aide du terme technique "pattern strategy" donné par nohar, rechercher sur le net...

Bon courage dans ta recherche.

Python permet de modifier dynamiquement la classe d'une instance: si p est instance de Chomeur, on peut écrire p.__class__ = Boucher. Comme Chomeur et Boucher n'ont peut être pas les mêmes attributs/méthodes, ce raccourci doit être utilisé avec précaution. Techniquement, le pattern State répond mieux (que Strategy) a ce cas d'utilisation.

Techniquement, le pattern State répond mieux (que Strategy) a ce cas d'utilisation.

Théoriquement, plutôt. Parce que dans la pratique ces deux patterns sont quasi-identiques.

-
Edité par nohar 28 février 2013 à 15:51:06

L'intérêt des patterns n'est pas côté réalisation (beaucoup sont semblables à quelques variations près) mais du côté cas d'utilisations associé à un nom qui associe un sens précis. Théoriquement, on pourrait les nommer P1, P2, ..., PN.  Ce faisant nous perdrions, dans la pratique, l'intérêt d'avoir un "nom" associé à un sens partagé par les développeurs d'un projet. Ce qui est quand même dommage car construire du sens avec peu de mots (et précis), est quand même l'intérêt des patterns. 

-
Edité par mps 28 février 2013 à 16:40:52