Oui sauf que sur la page française, une confusion entre encapsulation des données et masquage de l'information est entretenue alors qu'il s'agit de 2 concepts proches mais différents.
Si on parle du principe d'embarquer les données avec les traitements dans une même entité autonome: l'objet, par opposition au langages procéduraux, l'encapsulation est parfaitement prise en charge par Python.
Le masquage de donnée est un autre principe qui est destiné à renforcer l'encapsulation en n'autorisant l'accès aux objets qu'au travers de leur contrat/interface.
Ce principe est sensé protéger l'intégrité de l'objet contre des manipulations hasardeuses de plusieurs attributs dont les valeurs seraient interdépendantes et de contrôler l'accès à la structure de l'objet. Il confère donc une certaine sécurité sur ces données. Il assure aussi en principe une séparation stricte entre contrat et implémentation qui permet de faire évoluer cette implémentation sans impacter le contrat (le fameux exemple des nombres complexes cartésiennes qui deveinnent polaires)
Dans la pratique que remarque t'on ?
L'inviolabilité de la structure n'est jamais assurée à partir du moment ou le langage propose l'introspection.
Une convention telle que celle de Python qui se charge simplement de prévenir qu'on la transgresse est amplement suffisant.
Dans 90% des cas, chaque attribut dispose de ses accesseurs et des trésors d'ingéniosité sont déployés pour simplifier cet accès (fonctions ds les IDE, annotations, syntaxiques : a.x=2 qui renvoie en fait à un appel de méthode qu'on peut modifier en cas de changement de nom d'attribut, ....)
Pourtant:
Si un attribut x public devient y.
Quelle est la différence entre casser le contrat dans le code appelant (attention au tests unitaires un must-have pour python) et celle d'en faire un privé et obliger à créer 2 nouveaux accesseur getY/setY et déclarer les accesseur getX/setX en obsolete.
Cette fameuse stabilisation des contrats n'est bien souvent qu'un miroir aux alouettes.
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par El Titi . En réponse au journal Lamentations ou les remords d'un geek. Évalué à 3.
Si tu te réfères à la page anglaise:
http://en.wikipedia.org/wiki/Encapsulation_%28object-oriente(...)
Tu verras que ces 2 notions sont distinctes même si elle sont souvent confondues.
Si on parle du principe d'embarquer les données avec les traitements dans une même entité autonome: l'objet, par opposition au langages procéduraux, l'encapsulation est parfaitement prise en charge par Python.
Le masquage de donnée est un autre principe qui est destiné à renforcer l'encapsulation en n'autorisant l'accès aux objets qu'au travers de leur contrat/interface.
Ce principe est sensé protéger l'intégrité de l'objet contre des manipulations hasardeuses de plusieurs attributs dont les valeurs seraient interdépendantes et de contrôler l'accès à la structure de l'objet. Il confère donc une certaine sécurité sur ces données. Il assure aussi en principe une séparation stricte entre contrat et implémentation qui permet de faire évoluer cette implémentation sans impacter le contrat (le fameux exemple des nombres complexes cartésiennes qui deveinnent polaires)
Dans la pratique que remarque t'on ?
L'inviolabilité de la structure n'est jamais assurée à partir du moment ou le langage propose l'introspection.
Une convention telle que celle de Python qui se charge simplement de prévenir qu'on la transgresse est amplement suffisant.
Dans 90% des cas, chaque attribut dispose de ses accesseurs et des trésors d'ingéniosité sont déployés pour simplifier cet accès (fonctions ds les IDE, annotations, syntaxiques : a.x=2 qui renvoie en fait à un appel de méthode qu'on peut modifier en cas de changement de nom d'attribut, ....)
Pourtant:
Si un attribut x public devient y.
Quelle est la différence entre casser le contrat dans le code appelant (attention au tests unitaires un must-have pour python) et celle d'en faire un privé et obliger à créer 2 nouveaux accesseur getY/setY et déclarer les accesseur getX/setX en obsolete.
Cette fameuse stabilisation des contrats n'est bien souvent qu'un miroir aux alouettes.
Je vous laisse débattre.