Encapsulation et programmation orientée objet

[ZhaoXi]

Bonjour.

J'éprouve des difficultés dans la compréhension de l'encapsulation, notion liée à la programmation orientée objet. Il est dit que l'encapsulation permet de protéger les attributs d'une classe en les rendant immunisées à des modifications par l'extérieur, par exemple on ne peut pas modifier le type d'un attribut privé chaîne de caractères et le rendre entier par exempe. Mais, généralement, les méthodes ne sont pas privées. Cela veut-il dire qu'on peut modifier les méthodes d'une classe ?
En prenant l'exemple de Python, et la classe list, cela veut-il dire que je ne peux pas modifier le type de la taille d'une liste, mais que je peux modifier la méthode sort ?

J'espère que vous pourrez m'aider afin de comprendre cette notion fondamentale en programmation orientée objet.

Merci d'avance.
-----

[Jack]

Modifier de manière anarchique certains attributs peut rendre un programme instable. Le fait d'obliger de passer la des fonctions d'accès permet de limiter et surtout de reprendre le contrôle de la modification de ces attributs. Comme c'est celui qui a programmé sa classe qui en maîtrise en principe son fonctionnement, c'est à lui qu'il appartient de créer ces limitations d'accès en imposant ses fonction d'accès au lieu de laisser n'importe qui faire n'importe quoi.

Pour utiliser une analogie, pour vérifier le niveau d'huile dans le moteur d'une voiture, on a prévu une jauge pour l'utilisateur lambda plutôt que de le laisser démonter le moteur sans trop en connaitre les conséquences.

[pm42]

par exemple on ne peut pas modifier le type d'un attribut privé chaîne de caractères et le rendre entier par exempe.

Cela n'a rien à voir. Là, tu parles de programmation, quand on écrit le code et où on peut bien sur changer le type d'un attribut. Cela, on peut toujours.
L'encapsulation est un concept qui s'applique à l'exécution : le programmeur définit comment sont accédés les attributs.
Certains peuvent être en lecture seule, d'autres en lecture/écriture sans contrainte ou on peut avoir des contraintes à l'écriture.
Par exemple, un attribut qui contient un mois n'acceptera que des valeurs entre 1 et 12.

Mais, généralement, les méthodes ne sont pas privées. Cela veut-il dire qu'on peut modifier les méthodes d'une classe ?

Même confusion que plus haut entre la programmation et l'exécution.

En prenant l'exemple de Python, et la classe list, cela veut-il dire que je ne peux pas modifier le type de la taille d'une liste, mais que je peux modifier la méthode sort ?

Idem.

Ce que cela veut dire pour une List, c'est que tu peux modifier son contenu en ajoutant ou supprimant des éléments (je parle à l'exécution de ton programme).
Mais qu'elle peut avoir un attribut qui s'appelle "size" et que tu ne peux jamais modifier, seulement le lire.
Et que sa structure interne contient des attributs que tu ne peux ni lire ni écrire directement mais qui seront modifiés par les méthodes add et remove et lu par le méthode get.

[polo974]

Bonjour.
...
En prenant l'exemple de Python, ...

Merci d'avance.

Bonjour, Python est un drôle de langage qui permet de toujours (presque) tout modifier (casser). Il n'y a pas de variable privée

même celles qui commencent avec 2 underscore, elles sont justes préfixées par _<nomdelaclasse> ... et attention quand on subclasse avec des variables en __...

démo vite faite:

>>> class m:
...     def __init__(self):
...         self.a = 1
...         self._b = 2
...         self.__c = 3 # __c de la classe m
... 
>>> 
>>> 
>>> class sm(m):
...     def __init__(self):
...         self.__c = 13 # __c de la classe sm
...         super().__init__()
... 
>>> 
>>> s=sm()
>>> vars(s)
{'_sm__c': 13, 'a': 1, '_b': 2, '_m__c': 3}
>>> 
>>> s._c # pas accessible
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'sm' object has no attribute '_c'
>>> s._sm__c  # __c de la classe sm
13
>>> s._m__c  # __c de la classe m
3
>>>

on se retrouve "avec 2 variables" __c (préfixées par le nom de classe), une pour (exclusivement) chaque classe, pas d'héritage (direct) ! ! !

mais comme c'est trop simple, une variable qui commence et fini avec 2 _ se comporte encore autrement, mais là, on tape dans les entrailles de python, et ça peut faire une hémorragie interne...

[A voir en vidéo sur Futura]

[invite73192618]

démo vite faite:
(...)
on se retrouve "avec 2 variables" __c (préfixées par le nom de classe), une pour (exclusivement) chaque classe, pas d'héritage (direct) ! ! !

Pas compris c'est quoi le problème de cet exemple? Tu voudrais que le comportement soit différent genre ci-dessous?

>>> class m:
...     def __init__(self):
...         self.a = 1
...         self._b = 2
...         self.__c = 3 # __c de la classe m
... 
>>> 
>>> 
>>> class sm(m):
...     def __init__(self):
...         self.__c = 13 # __c de la classe sm
...         super().__init__()
... 
>>> 
>>> s=sm()
>>> vars(s)
{'a': 1, '_b': 2, '__c': 13}
>>> s.__c 
13
>>> s._sm__c # pas accessible
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'sm' object has no attribute '_sm__c'
>>> s._m__c # pas accessible
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'sm' object has no attribute '_m__c'
>>>

[polo974]

Pas compris c'est quoi le problème de cet exemple? ...
...

Le problème (pour moi (un peu vieux jeu)), c'est que selon le nom, une variable se comporte très différemment.

Dans le genre sorcier, c'est pas mal. Car là, une sous-classe n'accède pas à cette sorte de variable "privatisée" de la classe mère...
Et le mécanisme est mis en route juste par le nommage de la variable...
Bref, avant d'avoir lu les tréfonds de la doc python, eh bien, on peut s'arracher les cheveux un bout de temps...

(sinon, je viens de regarder du code javascript, ça me fait pleurer des larmes de sang... donc finalement python, c'est cool)

[invite73192618]

Le problème (pour moi (un peu vieux jeu)), c'est que selon le nom, une variable se comporte très différemment.

OK, mais quel serait le comportement que tu voudrais voir en cas de collisions liées à l'héritage?

[pm42]

(sinon, je viens de regarder du code javascript, ça me fait pleurer des larmes de sang... donc finalement python, c'est cool)

Tous les langages ont leur faiblesses et effectivement, les classes en Python ne sont pas top coté lisibilité/cohérence mais bon, on peut faire pas mal sans.

Pour Javascript, les 1ères versions étaient faibles. Les versions récentes permettent d'écrire du code concis et propre et comme Python, l'utilisation plutôt en fonctionnel qu'en objet fait gagner pas mal.
Mais surtout, on peut utiliser Typescript qui est vraiment pas mal et qui transpile en Javascript.

[invite73192618]

Mais surtout, on peut utiliser Typescript qui est vraiment pas mal et qui transpile en Javascript.

Pourrais-tu nous montrer un exemple équivalent à #4 pour qu'on se rende compte de la différence de lisibilité/cohérence? (ou un autre exemple si c'est plus clair avec un autre exemple)

[pm42]

En Typescript, c'est différent : une variable public qui a le même nom dans les 2 classes est la même.

Donc si tu fais :

class m {
  c: String
  constructor(cc: String) {
    this.c = cc;
  }
}

class sm {
  c: String
  constructor(cc: String) {
    super(cc);
  }
}

Ca marche, tu n'as pas de conflit et c est la même variable. C'est parce que les "classes" sont en fait des ensemble de clé/valeur et qu'on peut ajouter des clés dynamiquement en Javascript.

Si tu veux éviter ça, tu déclares ta variable c private et tu lui mets éventuellement des getter/setter. Alors la sous-classe ne pourra pas déclarer une variable du même nom et tu n'auras pas de risque de conflit.

Note que je ne dis pas que Typescript est un super langage : il est au dessus de Javascript et donc il hérite des particularités qui me laissent perplexe. Mais il apporte des classes plus propres, les interfaces, les génériques et pas mal d'autres choses.

[Jack]

Ca fait toujours autant plaisir de voir l'intérêt du le primo posteur pour les réponses apportées à ses questions ...

[invite73192618]

les "classes" sont en fait des ensemble de clé/valeur et qu'on peut ajouter des clés dynamiquement en Javascript.

Compris, merci.

[polo974]

OK, mais quel serait le comportement que tu voudrais voir en cas de collisions liées à l'héritage?

En fait, j'aurais préféré (ne pas avoir à me dire RTFM (chapitre 9 de la doc python, sous chapitre 6...)) un truc plus visible genre quelque part dans le __init__ obligation de mettre un terme genre private ou local devant la création de la variable...

Car l'idée en soit est intéressante, mais c'est le risque de tomber "dedans" à "l'insu de son plein gré" qui me chagrine...

[invite73192618]

c'est le risque de tomber "dedans" à "l'insu de son plein gré" qui me chagrine...

Ok, oui c'est jamais très agréable la première fois qu'on tombe sur un truc imprévu, genre une limite dans le nombre de boucles ou même une instabilité numérique. Dès fois faut juste s'y faire, mais dans d'autre cas c'est une indication qu'il pourrait y avoir une version de python qui se comporte différemment sur tel ou tel aspect. On pourrait appeler ça Python 0.x

[ZhaoXi]

Bonsoir.

Je m'excuse pour ma réponse tardive je viens de m'installer dans une nouvelle école et j'avais quelques problèmes à régler.
Je n'ai pas pu comprendre toute la discussion car je n'y connais rien à Java, mais sinon je comprends un peu mieux l'encapsulation, merci pour vos réponses !
J'ai essayé le code que vous avez écrit @polo974 et je ne remarque pas l'effet des 2 underscores :

Je ne sais pas comment écrire le code Python dans un cadre propre à lui comme dans les éditeurs, veuillez m'excuser.

Voilà j'ai repris cette partie du code :

class m:
    def __init__(self):
        self.a=1
        self._b=2
        self.__c=3
        
class sm(m):
    def __init__(self):
        self.__c=13
        super().__init__()


s=sm()
vars(s)

Et j'ajoute cela à la fin :

s.a=100


s._b=200


s._m__c=300


print(s.a)
print(s._b)
print(s._m__c)

Et voilà la réponse de Python :

(executing cell "" (line 1 of "<tmp 1>"))
100
200
300


Donc que l'on ajoute 1 seul _ ou 2 des _ , ca n'a eu aucun effet non ?

J'espère que vous pourrez m'aider encore une fois afin de comprendre où se cache le problème.

Merci d'avance.

[polo974]

bonjour,
en python, il y a juste une convention pour les variables à un seul _ : ce sont des variables qu'on ne devrait pas toucher depuis l'extérieur de l'objet, mais rien ne l'interdit (c'est même moins conventionnel que l'usage de self. qui lui est "réglementé" mais pas imposé).

ensuite, comme tu n'a pas fait de :

print (s.__c)

tu n'as pas pu constaté que c'est interdit, et ça sort une erreur. les variables (et fonctions) commençant avec double _ ET ne finissant pas par double _ sont privées au niveau de la classe. elles ne sont même pas héritées...

c'est décrit dans la doc python chapitre 9.6.

ce truc de double _, ça fait un peu partie du poil à gratter du python...

[pm42]

les variables (et fonctions) commençant avec double _ ET ne finissant pas par double _ sont privées au niveau de la classe. elles ne sont même pas héritées...

Non. C'est pourtant clairement expliqué dans le lien que tu as donné.
Ces variables sont renommés pour incorporer le nom de la classe.

On peut donc faire :

class Foo:
  __f = 42

foo = Foo()
print(foo._Foo__f)

Et on accède à la variable.

Et elle est héritée bien sur :

class Bar(Foo):
  def show(self):
    print(self._Foo__f)

bar = Bar()
bar.show()

Dans les 2 cas, on affiche 42 et on a bien eu accès à la variable __f.

[polo974]

ok, je corrige: "... ne sont pas exposées sous leur nom".

[ZhaoXi]

Bonjour.

Merci pour vos réponses. Mais je ne comprends toujours pas ce caractère "privé" des variables commençant par deux _ (et ne finissant pas par des _). Car on peut toujours y accéder même si c'est sous un nom différent et puis on peut changer sa valeur...

Merci par avance.

[pm42]

Mais je ne comprends toujours pas ce caractère "privé" des variables commençant par deux _ (et ne finissant pas par des _). Car on peut toujours y accéder même si c'est sous un nom différent et puis on peut changer sa valeur...

Python ne supporte pas le concept de variable privée. Ce mécanisme a été mis en place pour éviter les conflits de nom.
Pour le reste, c'est de la convention : les programmeurs savent qu'ils ne doivent pas utiliser les variables qui commencent par _ (ou __).

[ZhaoXi]

Je vois, c'est donc plutôt une convention. Mais sinon lorsqu'on travaille avec d'autres languages (fortement typés) on ne pourra pas modifier la variable sauf si le programmeur a mis des méthodes pour cela ?

Merci par avance.

[pm42]

Mais sinon lorsqu'on travaille avec d'autres languages (fortement typés) on ne pourra pas modifier la variable sauf si le programmeur a mis des méthodes pour cela ?

En effet. Python n'est sans doute pas le bon langage pour apprendre ces concepts.