Réponse.

Historique de la question :

L'encapsulation est l'un des principes clés de la POO, apparus en C++ dès ses débuts. L'idée est de limiter l'accès à l'état interne de l'objet en ne fournissant que des interfaces réfléchies pour interagir avec celui-ci. En C++, l'encapsulation est formalisée par les niveaux d'accès des membres de la classe : public, protected, private.

Problème :

Si l'on n'utilise pas l'encapsulation, l'état interne des objets peut être modifié de n'importe où dans le programme, ce qui entraîne des erreurs, des bugs difficiles à diagnostiquer et une fiabilité générale réduite. Un accès excessivement restreint peut rendre la maintenance et l'utilisation des classes difficiles.

Solution :

Il est important de bien séparer l'interface de la classe (section publique) et l'implémentation (private/protected). Utiliser des méthodes spéciales (getters/setters) pour accéder aux données importantes. Pour les logiques complexes, séparer le mécanisme à l'aide de classes supplémentaires ou de templates. Utiliser des méthodes const pour garantir l'immuabilité de l'état.

Exemple de code :

class Counter {
private:
    int value;
public:
    Counter() : value(0) {}
    void increment() { ++value; }
    int get() const { return value; }
};

Caractéristiques clés :

Trois niveaux d'accès : public, protected, private.
La possibilité de ne réaliser que les méthodes nécessaires pour interagir avec l'objet.
La limitation de l'accès aux données internes et aux méthodes.

Questions pièges.

Peut-on accéder à un membre private d'un autre objet de la même classe directement à l'intérieur d'une méthode ?

Oui, à l'intérieur des méthodes de la classe, on peut accéder aux membres private d'autres objets de la même classe.

class Example {
    int val;
public:
    void copyVal(const Example& other) { val = other.val; } // Pas d'erreur !
};

Une fonction amie peut-elle accéder aux membres private de la classe ?

Oui, une fonction friend a un accès complet aux membres private/protected de la classe.

Peut-on rendre le constructeur privé ? Pourquoi est-ce nécessaire ?

Oui, des constructeurs privés sont souvent utilisés dans des singletons et des méthodes de fabrication pour contrôler la création des instances de la classe.

Erreurs typiques et anti-patterns

Tous les membres de la classe sont déclarés publics
Les getters/setters deviennent des enveloppes formelles sans réelle restriction
Violation du SRP : Open-Access Class

Exemple de la vie quotidienne

Cas négatif

La classe BankAccount contient une variable publique balance. N'importe quel code externe peut modifier le solde directement, ce qui entraîne des erreurs presque impossibles à enquêter.

Avantages :

Facile à utiliser

Inconvénients :

Pas de contrôle sur les modifications, impossible d'ajouter des restrictions ou un audit

Cas positif

La variable balance est cachée, seules des méthodes protégées pour modifier le solde existent. Les vérifications sont effectuées à l'intérieur de la classe.