Principe d'encapsulation en python

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