Encapsulation et protection des données¶

Jusqu’ici, on a appris à créer des objets avec :

des attributs
des méthodes
un état qui évolue dans le temps

Mais il y a un petit problème.

Pour l’instant, tout est accessible de partout.

Et même si ça marche, ce n’est pas toujours une bonne idée.

Le problème : trop de liberté¶

Prenons un exemple simple :

compte.solde = -1_000_000

Techniquement, Python ne dit rien. Mais logiquement… ça n’a aucun sens, on ne peut pas avoir d'argent négatif (en vrai avec les dettes on peut mais on va dire que dans notre cas non).

Le souci, ce n’est pas que le code plante. Le souci, c’est que n’importe quelle partie du programme peut casser l’état d’un objet.

Plus un programme grandit :

plus ce genre de problème devient fréquent
plus les bugs sont difficiles à retrouver

L’idée de l’encapsulation¶

L’encapsulation, c’est une idée très simple :

Un objet doit contrôler lui-même son propre état.

Autrement dit :

on évite de modifier directement les attributs sensibles
on passe par des méthodes
l’objet décide ce qui est autorisé ou non

Attributs “privés” en Python¶

En Python, il n’existe pas de vrais attributs privés comme dans certains autres langages.

Mais il existe des conventions, et elles sont très importantes.

Le simple underscore `_`¶

Un attribut qui commence par _ est considéré comme interne à la classe.

class CompteBancaire:
    def __init__(self, solde):
        self._solde = solde

Cela signifie :

“Tu peux y accéder… mais tu ne devrais pas.”

Ce n’est pas une protection technique, c’est une protection mentale.

Modifier l’état via des méthodes¶

Au lieu de faire ça :

compte._solde -= 50

On préfère écrire :

compte.retirer(50)

Et dans la méthode :

class CompteBancaire:
    def __init__(self, solde):
        self._solde = solde

    def retirer(self, montant):
        if montant <= self._solde:
            self._solde -= montant

Avantages :

l’objet reste cohérent
les règles sont centralisées
le code est plus lisible
les erreurs sont évitées

Pourquoi c’est vraiment important¶

Sans encapsulation :

l’état peut devenir invalide
les règles sont éparpillées
chaque modification est risquée

Avec encapsulation :

une seule source de vérité
un comportement prévisible
un code beaucoup plus robuste

Et surtout :

si les règles changent, on modifie un seul endroit.

Quizz¶

Regardez ce code :

class Personnage:
    def __init__(self, vie):
        self.vie = vie

Quel est le principal problème de cette classe ?
- Elle est trop courte
- Elle ne respecte pas la syntaxe Python
- *N’importe quelle partie du programme peut mettre la vie à une valeur incohérente, par exemple négative.
- Il manque une méthode `print`
> Sans encapsulation, l’état peut être modifié librement, ce qui rend le programme fragile.

Exercice pratique¶

Reprenez une classe que vous avez déjà écrite (par exemple Mamie ou CompteBancaire).

Identifiez les attributs qui ne devraient pas être modifiés directement

Renommez-les avec un _

Créez des méthodes pour :

modifier l’état proprement
empêcher les valeurs incohérentes

Exemples de règles possibles :

pas de solde négatif
pas de niveau inférieur à 1
pas de points d'expérience flottants

En résumé¶

L’encapsulation permet de :

protéger l’état d’un objet
éviter des bugs difficiles à détecter
centraliser les règles
écrire du code plus propre et plus fiable

La programmation orientée objet ne consiste pas à cacher pour cacher,
mais à reprendre le contrôle sur l’état de ses objets.

Dans la page suivante, on va voir comment rendre nos objets encore plus agréables à utiliser, en personnalisant leur affichage.