Principe d'encapsulation en python

Bonsoir,

Contrairement à d'autres langages de programmation comme java où le principe d'encapsulation est vraiment respecté (attribut private ou protected). En python, ce n'est pas la cas. Alors, je voudrais savoir quel serait son importance en python si on a toujours la possibilité d'accéder à une variable protégée hors classe. Par exemple :

Code:

---

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

class P:   def __init__(self,x): self.__x = x   def get_x(self): return self.__x   def set_x(self, x): self.__x = x   p1 = P(12) p1._P__x >>>12

---

Citation:

---

Envoyé par master4

Alors, je voudrais savoir quel serait son importance en python si on a toujours la possibilité d'accéder à une variable protégée hors classe.

---

Bonjour

C'est un fait connu des programmeurs Python qui l'acceptent. Donc l'importance sera celle que toi tu lui donnes par rapport à tes besoins, ton environnement de travail (seul, en groupe), etc...

Salut,

Ceci suit le principe qui veut que "En Python nous sommes adultes et consentants"

Maintenant, tu peux rendre un attribut en lecture seule par divers moyens.
Exemple:

Code:

---

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

class P: _instanciated = False def __init__(self,x): self.__x = x self.y = 6 self._instanciated =True   def __setattr__(self, name, value): if self._instanciated and name == '__x': raise NotImplementedError setattr(P, name, value)   p = P(24) print(p.__x) print(p.y) p.__x = 14

---

Je suis d'accord avec Sve@r, dans le sens où tout dépendra du besoin... Après tout, tout se justifie !

Alors pourquoi pas d'encapsulation en python,

• Code facile à lire et à comprendre
• La concision du code (il est inutile de faire du setter-getter et se blinder de lignes à n'en plus finir)
• La maintenance du code facile (modifier un attribut dynamiquement est un jeu d'enfants)

Et comme la philosophie du langage "zen of python" le dit: Simple is better than complex, tout cela tombe sous le sens.

Maintenant si tu en as besoin, pourquoi pas, dans ce cas on utilise les property qui permettent de contrôler la lecture-écriture-suppression des attributs dans une classe. La PEP8 dit ceci,

Citation:

---

For simple public data attributes, it is best to expose just the attribute name, without complicated accessor/mutator methods. Keep in mind that Python provides an easy path to future enhancement, should you find that a simple data attribute needs to grow functional behavior. In that case, use properties to hide functional implementation behind simple data attribute access syntax.

---

avec une petite parenthèse,

Citation:

---

Avoid using properties for computationally expensive operations; the attribute notation makes the caller believe that access is (relatively) cheap.

---

Alors même si tu en sens le besoin, réfléchis bien ! Les conséquences sont assez nombreuses... et plus il y a de conséquences, plus on te demandera de justifier tes choix de conception. En python on cherche le maximum de simplicité, ce qui impose un maximum de responsabilité, et ça n'empêche absolument pas python d'être performant, tant dans l'écriture du code, que dans l'exécution des tâches.

Salut,

Citation:

---

Envoyé par master4

Alors, je voudrais savoir quel serait son importance en python si on a toujours la possibilité d'accéder à une variable protégée hors classe.

---

Si vous utilisez les variables protégées de la bibliothèque X créée par le développeur D vous aurez (peut être) des soucis si, à la version suivante, le développeur D, supprime ou modifie ces variables. Comme elles ne font pas partie de l'"interface publique", il est libre de les utiliser comme il veut... Et si votre code ne fonctionne plus parce que vous n'avez pas respecté l'interface, c'est votre problème (pas le sien).

Donc à court terme, votre code fonctionne... mais à plus long terme, il faudra (peut être) le revoir. Avec un mécanisme de protection fort, comme on le trouve dans Java ou C++, impossible d'utiliser une variable/attribut protégé. Et le risque d'avoir à revoir le code à cause de cela est nul.... et vous pouvez installer/utiliser les nouvelles versions des bibliothèques, à priori, sans risque dès que l'interface publique reste identique.

Ceci dit, attributs privés et protégés existent bel et bien et si rien n'est testé lorsqu'on exécute un script qui accède à des attributs protégés, on peut lire le code ou l'analyser avec un pylint ou équivalent (qui testent aussi ce genre de chose).
Donc, c'est un petit risque dont on peut se protéger, en cas de besoin.

- W

Citation:

---

Envoyé par VinsS

Code:

---

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

class P: _instanciated = False def __init__(self,x): self.__x = x self.y = 6 self._instanciated =True   def __setattr__(self, name, value): if self._instanciated and name == '__x': raise NotImplementedError setattr(P, name, value)   p = P(24) print(p.__x) print(p.y) p.__x = 14

---

---

Il me semble que ton print(p.__x) ne fonctionnera pas (puisque la variable se nomme en réalité p._P__x). De même le test name == '__x' devrait plutôt être name == '_P__x'. Ceci dit j'apprécie ce code et son inventivité :plusser: :applo:

Bien vu, j'ai copié la première mouture, le bon code est ceci:

Code:

---

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

class P: _instanciated = False def __init__(self,x): self.x = x self.y = 6 self._instanciated =True   def __setattr__(self, name, value): if self._instanciated and name == 'x': raise NotImplementedError setattr(P, name, value)   p = P(24) print(p.x) print(p.y) p.x = 14

---

et donc

Code:

---

1 2 3 4 5 6 7 8 9 10

vincent@djoliba:~/Bureau$ python3 private.py 24 6 Traceback (most recent call last): File "private.py", line 16, in <module> p.x = 14 File "private.py", line 10, in __setattr__ raise NotImplementedError NotImplementedError

---

La raison d'utiliser "setattr(P, name, value)" est parce que "setattr(self, name, value)" entrainerait une récursion infinie.

Citation:

---

Envoyé par VinsS

La raison d'utiliser "setattr(P, name, value)" est parce que "setattr(self, name, value)" entrainerait une récursion infinie.

---

J'ai bien vu quand j'ai testé avec "self" :aie:

C'est dommage car ça implique le nom de la classe dans une de ses méthodes. Si le nom change, faut reprendre le code...

J'ai trouvé une solution pour pallier : eval("setattr(%s, %s, %s)" % (self.__class__.__name__, name, value)) (mais faut que ton objet hérite de "object") (et surtout que wiztricks ne voit jamais mon eval :fessee: :mrgreen:)...

[edit]Euh en fait il y a un autre souci: "_instanciated" est un membre de classe statique. Il existe donc à un seul exemplaire pour toutes les instances de ton objet. Rajoute p2 = P(42) en dessous de ton p = P(24) et :mur:
J'ai trouvé un truc mais là c'est le grand bricolage de la honte...

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class P(object): def __init__(self, x): self._instanciated=False self.__x=x self._instanciated=True def __setattr__(self, name, value): if hasattr(self, "_instanciated")\ and self._instanciated\ and name.startswith("_%s__" % self.__class__.__name__): raise AttributeError("%s" % name) setattr(P, name, value)

---

il diffère un peu car je l'ai écrit dans le but de protéger juste les membres privés (commençant par "__")...

Merci à tous de vos réponse !
Si j'ai bien compris ce que vous avez dit. On peut donc créer un programme en Python sans utiliser le principe d’encapsulation et ne pas avoir des problèmes par la suite ?

Citation:

---

Envoyé par master4

Si j'ai bien compris ce que vous avez dit. On peut donc créer un programme en Python sans utiliser le principe d’encapsulation et ne pas avoir des problèmes par la suite ?

---

Les soucis ne viennent que de la façon de faire des développeurs. Si tu bosses avec des gens consciencieux qui savent ce qu'ils font et qui respectent les conventions, tu n'auras jamais de problème (y compris dans les langages encapsulés comme Java ou C++).

Citation:

---

Envoyé par Sve@r

Les soucis ne viennent que de la façon de faire des développeurs. Si tu bosses avec des gens consciencieux qui savent ce qu'ils font et qui respectent les conventions, tu n'auras jamais de problème (y compris dans les langages encapsulés comme Java ou C++).

---

Là, je commence à voir un peu plus clair. Donc vu que les programmes qu'on développe sont appelés, tôt ou tard, à être modifiés ou bidouillés par des tierces personnes qui nous seront peut-être inconnues. Il est donc plus judicieux de toujours encapsuler ?

https://www.python-course.eu/python3_properties.php : pour une explication pratique

Ne pas mettre des getters/setters avant d'en avoir besoin s'approche de https://fr.wikipedia.org/wiki/YAGNI

Citation:

---

Envoyé par nicolas581

https://www.python-course.eu/python3_properties.php : pour une explication pratique

Ne pas mettre des getters/setters avant d'en avoir besoin s'approche de https://fr.wikipedia.org/wiki/YAGNI

---

Moi, je me dit que pour me prémunir contre les éventuels personnes mal intentionnées qui pourraient détruire le programme que je développe. Il est mieux de protéger mes variables. Si par exemple, je me dis : "bon, pour mon programme, je n'ai pas besoin d'encapsuler mes variables, car personne ne pourrait mal les utiliser...". Là, je trouve que je cours un risque parce que je ne connais pas l'intention de tout le monde. Pour assurer sa sécurité autant tout protéger, mieux vaut "prévenir que guérir".

Citation:

---

Envoyé par master4

Moi, je me dit que pour me prémunir contre les éventuels personnes mal intentionnées qui pourraient détruire le programme que je développe. Il est mieux de protéger mes variables. Si par exemple, je me dis : "bon, pour mon programme, je n'ai pas besoin d'encapsuler mes variables, car personne ne pourrait mal les utiliser...". Là, je trouve que je cours un risque parce que je ne connais pas l'intention de tout le monde. Pour assurer sa sécurité autant tout protéger, mieux vaut "prévenir que guérir".

---

Que tu protèges ou non tes variables ne changera rien, étant donné qu'il aura accès à ton code pour faire cette modification.

Quand on utilise un langage tel que python, il est rare d'avoir le besoin de protéger la lecture du code, mais si c'est le cas, on peut déjà le rendre moins facilement lisible pour 98% des utilisateurs lambda, rien que par une compilation.

Après pour plus de sécurité, c'est bien plus complexe, mais sur les 2% qui liront ton code, 1% seront capables de le déchiffrer et diffuser sur le net pour cette fois-ci un grand nombre de personnes. Mais pour ça faut-il que le code en vaille la chandelle, et que le prix du logiciel soit prohibitif.

Citation:

---

Envoyé par master4

Là, je commence à voir un peu plus clair. Donc vu que les programmes qu'on développe sont appelés, tôt ou tard, à être modifiés ou bidouillés par des tierces personnes qui nous seront peut-être inconnues. Il est donc plus judicieux de toujours encapsuler ?

---

Pourquoi faire ?
Si les tierces personnes modifient et que, suite à ces modifs, ton programme ne fonctionne plus chez-elle, ce sera leur problème...

Citation:

---

Envoyé par Sve@r

Pourquoi faire ?
Si les tierces personnes modifient et que, suite à ces modifs, ton programme ne fonctionne plus chez-elle, ce sera leur problème...

---

:haha::mouarf:

Pourriez-vous me donner quelques exemples des cas où ce serait pertinent d'encapsuler ?

Citation:

---

Envoyé par master4

Pourriez-vous me donner quelques exemples des cas où ce serait pertinent d'encapsuler ?

---

Quand vous écrirez du code où ne pas le faire pourrait se traduire par une perte de temps (et/ou de revenus)... i.e. lorsque vous ne pourrez pas vous permettre de prendre ce risque.
Autrement dit, protéger les attributs n'ajoutant rien aux fonctionnalités du code, il pourra être pertinent d'encapsuler qu'en fonction d'un contexte non-technique: le client, le type d'application, les engagements des différents intervenants côté maintenance, performances,....

- W

Citation:

---

Envoyé par master4

Pourriez-vous me donner quelques exemples des cas où ce serait pertinent d'encapsuler ?

---

Chaque fois que ça te permettra de contrôler ce qui entre tout en laissant l'utilisateur libre de travailler

Prenons un exemple tout con: un objet destiné à gérer une personne

Code:

---

1 2 3

class cPersonne(object): def __init__(self, nom): self.nom=nom

---

Avec cet objet, l'utilisateur peut très bien créer une personne puis afficher ou changer ensuite son nom

Code:

---

1 2 3 4

v=cPersonne("Arthur") print(v.nom) v.nom="Perceval" print(v.nom)

---

voire aussi y mettre rien du tout (v.nom="").

Maintenant, si on place le nom en privé mais qu'on rajoute un getter et un setter...

Code:

---

1 2 3 4 5 6 7 8

class cPersonne(object): def __init__(self, nom): self.__nom=nom def __get_nom(self): return self.__nom def __set_nom(self, nom): if not nom: raise IOError("Pas de nom vide") self.__nom=nom nom=property(__get_nom, __set_nom)

---

Avec ça, rien ne change pour l'utilisateur. Il peut toujours créer sa personne et afficher ou changer de nom sans même changer sa syntaxe habituelle (copier/coller de mon code précédent)

Code:

---

1 2 3 4

v=cPersonne("Arthur") print(v.nom) v.nom="Perceval" print(v.nom)

---

Chaque fois qu'il fait appel à v.nom, si c'est en sortie alors le bouzin appelle en interne __get_nom et si c'est en affectation alors ça appelle __set_nom.
Mais là toi tu contrôles ce qui entre. Et s'il tente d'entrer un nom vide, là il aura un "IOError" qu'il peut alors gérer de son côté.

Bref je vois ça plus comme une volonté "d'aide" à l'utilisateur qu'une volonté de le bloquer (même si quelque part les deux vont un peu ensembles). Disons que ça le bloque un peu mais ça évite ensuite à ton truc de planter parce qu'il aura entré n'importe quoi.
Maintenant, s'il force le truc et qu'il tape v._cPersonne__nom=None et qu'il vient ensuite pleurer parce que ça plante, tu lui diras gentiment d'aller se faire...

Citation:

---

Envoyé par Sve@r

Chaque fois que ça te permettra de contrôler ce qui entre tout en laissant l'utilisateur libre de travailler

---

Sauf que "property" et "protection des variables" n'ont rien à voir (et donc on ne les utilise pas pour les mêmes besoins).

- W

Citation:

---

Envoyé par wiztricks

Quand vous écrirez du code où ne pas le faire pourrait se traduire par une perte de temps (et/ou de revenus)... i.e. lorsque vous ne pourrez pas vous permettre de prendre ce risque.
Autrement dit, protéger les attributs n'ajoutant rien aux fonctionnalités du code, il pourra être pertinent d'encapsuler qu'en fonction d'un contexte non-technique: le client, le type d'application, les engagements des différents intervenants côté maintenance, performances,....

- W

---

Merci !

Citation:

---

Bref je vois ça plus comme une volonté "d'aide" à l'utilisateur qu'une volonté de le bloquer (même si quelque part les deux vont un peu ensembles). Disons que ça le bloque un peu mais ça évite ensuite à ton truc de planter parce qu'il aura entré n'importe quoi.
Maintenant, s'il force le truc et qu'il tape v._cPersonne__nom=None et qu'il vient ensuite pleurer parce que ça plante, tu lui diras gentiment d'aller se faire...

---

Merci @Sve@r pour ton exemple, je le trouve très pratique. Cela m'a permis de comprendre dans quel contexte encapsuler en python.:yaisse2:

Citation:

---

Envoyé par master4

Bonsoir,

Contrairement à d'autres langages de programmation comme java où le principe d'encapsulation est vraiment respecté (attribut private ou protected). En python, ce n'est pas la cas. Alors, je voudrais savoir quel serait son importance en python si on a toujours la possibilité d'accéder à une variable protégée hors classe.

---

Bonjour,

Bien qu'une réponse ai été donnée, je voudrai intervenir pour préciser cette notion d'encapsulation qui n'a pas l'air d'être comprise (et c'est courant…). Je vais peut-être répéter certaines choses qui ont été écrites mais je souhaite insister sur le concept.

L'encapsulation est un principe du paradigme "Orienté Objet". Il n'est donc pas lié à une implémentation technique et ne doit pas être confondu avec la visibilité. Un langage comme Java (que je prends en exemple du fait de mon expérience dans le domaine) met en œuvre de manière stricte la déclaration de visibilité, mais plus de 90 % du code Java en informatique de gestion n'applique pas le principe d'encapsulation (la plupart du temps parce que la conception n'est pas orientée objet).

Le principe de l'encapsulation consiste à masquer l'implémentation d'un objet. L'erreur classique consiste à associer ce principe à une considération liée à la sécurité alors que c'est un concept lié à l'évolutivité. En séparant l'implémentation d'un objet de sa fonction, lors de la conception de cet objet, vous définissez par sa visibilité publique le contrat qui définit comment cet objet sera utilisé. Le message derrière une déclaration privée est que vous informez les utilisateurs de votre objet que pour ce composant, vous ne vous engagez pas sur son comportement extérieur. Ainsi, vous avez une conception qui vous laisse libre de l'évolution de votre implémentation sans impact sur les interfaces dont la modification de l'existant lors de l'évolution.

Ah oui, "ce composant"…*Dans votre exemple, vous vous appuyez sur les attributs, mais l'encapsulation concerne également les méthodes. Une méthode "privée" n'est pas destinée à être appelée de l'extérieur.

Guido Van Rossum a choisi l'approche Open-Kimono (oui, oui… ) et en soi, ce n'est pas un problème. Votre job est de fournir un objet cohérent de par sa conception pour un usage. Si vous déclarez un attribut (les objets en Python n'ont que des attributs, certains sont des callables) en privé par la convention de l'underscore et que quelqu'un appelle directement cet attribut privé, il en prend la responsabilité. Par exemple :

Code:

---

1 2 3 4 5 6 7 8

class Personne: def __init__(self, age): self.age(age)   def age(valeur): if valeur < 0: raise ValueError('On ne gere que ceux qui sont deja ne') self._age = valeur

---

Si un utilisateur de votre code fait un

Code:

---

>>> ma_personne._age = -24

---

Et bien c'est sa responsabilité si le logiciel ne fonctionne pas par la suite. C'est un des principes du développement en Python : vous pouvez faire ce que vous voulez, mais assumez-en la responsabilité ;)

Autre point, dans votre code, vous utilisez une déclaration du type

Code:

---

_{2,}[a-zA-Z0-9_]*[a-zA-Z0-9]_?

---

(oui allez, une révision des regex… :p ). Ce n'est pas une déclaration destinée à "protéger" un attribut mais à mettre en œuvre le name-mangling, une technique destinée à assurer l'unicité d'un nom principalement lors de la mise en œuvre de l'héritage.

Respectez donc les conventions : pas de _ pour un attribut public, un _ pour déclarer que l'attribut est privé, __ pour déclarer un aspect spécial (qui dépend de la fin du nom).

Merci @dad3zero pour cet éclaircissement :)