Au Chapitre 1, n'importe qui pouvait écrire voiture.NombreDePortes = -12 sans que personne ne proteste. Le compilateur accepte, l'objet se retrouve dans un état impossible. C'est le signe que nos attributs ne sont pas protégés. Dans ce chapitre, on découvre les deux mots-clés qui posent les bases de la solution : public et private.
La fin du Chapitre 1 a laissé un trou : voiture.NombreDePortes = -12 est accepté sans broncher. Ce chapitre regarde ce trou de plus près, et pose la première pierre pour le boucher.
À la fin de ce chapitre, tu seras capable de :
public et private correctement.Reprends la classe Voiture du Chapitre 1 :
class Voiture
{
public string Marque;
public string Couleur;
public int NombreDePortes;
}
Et son utilisation :
Voiture maVoiture = new Voiture();
maVoiture.Marque = "Peugeot";
maVoiture.NombreDePortes = 5; // Cohérent.
maVoiture.NombreDePortes = -12; // Absurde. Mais accepté.
maVoiture.NombreDePortes = 9999; // N'importe quoi. Accepté aussi.
Le compilateur ne bronche pas. À l'exécution, rien n'explose. L'objet est dans un état impossible, et personne ne le sait.
Ce n'est pas spécifique à Voiture. Le même problème touche n'importe quelle classe avec des attributs public :
Personnage hero = new Personnage();
hero.Pv = -9999; // Personne ne proteste.
hero.Niveau = -42; // Idem.
🧠 L'idée à saisir : la responsabilité de protéger les données d'un objet doit être à l'intérieur de cet objet. C'est à l'objet de refuser ce qui n'a pas de sens — pas au code appelant de penser à vérifier à chaque ligne.
Pour ça, il faut commencer par fermer la porte de l'extérieur. C'est le rôle de la visibilité.
public et privateEn C#, chaque membre d'une classe (attribut, méthode, propriété…) a une visibilité. Elle décide d'où ce membre peut être lu ou modifié.
Deux mots-clés à connaître pour démarrer :
| Mot-clé | Accessible depuis | Usage typique |
|---|---|---|
public |
N'importe où dans le projet | Méthodes, propriétés (l'interface de l'objet) |
private |
Uniquement à l'intérieur de la classe | Attributs internes (les données privées) |
💡 Si on ne met rien, C# considère le membre comme
privatepar défaut. On préfère quand même l'écrire explicitement — c'est plus lisible.
Voiture privésclass Voiture
{
private string marque; // ← private
private string couleur; // ← private
private int nombreDePortes; // ← private
}
ℹ️ Convention de nommage : les attributs privés s'écrivent traditionnellement en camelCase (première lettre minuscule) :
nombreDePortes. Les propriétés et méthodes publiques s'écrivent en PascalCase (première lettre majuscule) :NombreDePortes,Demarrer(). On verra l'intérêt de cette distinction au chapitre suivant.
Reprends maintenant ton Program.cs du Chapitre 1 :
Voiture maVoiture = new Voiture();
maVoiture.marque = "Peugeot"; // ❌ Erreur de compilation
maVoiture.couleur = "Rouge"; // ❌
maVoiture.nombreDePortes = 5; // ❌
Dans Rider, tu vois apparaître une erreur en rouge sur chacune de ces lignes :
'Voiture.marque' is inaccessible due to its protection level
C'est exactement ce qu'on voulait. Le compilateur empêche maintenant n'importe qui de modifier les données de la voiture en passant par-dessus la classe.
Sauf que… on a un nouveau problème : on ne peut plus rien faire avec notre voiture. On a fermé la porte, mais on n'a pas encore la clé.
⚠️ Erreur classique : passer en
privatesans prévoir comment l'extérieur va lire et écrire les données. La classe devient inutilisable. Si tu casses tout tonProgram.csen mettantprivatepartout, c'est normal — la solution est dans les deux chapitres suivants.
L'encapsulation, c'est l'idée que les données d'un objet sont cachées à l'intérieur de cet objet, et qu'on n'y accède que par des points d'entrée contrôlés.
La règle de base, à retenir une fois pour toutes :
🧠 Les attributs sont
private. Les points d'accès sontpublic.
Schématiquement :
┌─────────────────────────────┐
│ class Voiture │
│ │
│ private string marque; │ ← invisible de l'extérieur
│ private int nbPortes; │
│ │
Program.cs ──► │ public ... Marque ... │ ← seule porte d'entrée
│ public ... NbPortes ... │
│ │
│ public void Demarrer() │ ← idem pour les actions
└─────────────────────────────┘
Tout ce qui dépasse à l'extérieur de la classe, c'est l'interface publique de l'objet. C'est elle qui décide ce qu'on peut faire avec lui, et dans quelles limites.
Les méthodes Demarrer(), AfficherInfos() du Chapitre 1 sont déjà public — c'est normal, elles sont faites pour être appelées depuis l'extérieur. Ce qui change ici, c'est que les données elles, deviennent private.
Reprends ton projet du Chapitre 1. Passe tous les attributs de Voiture en private, puis essaie de lancer le programme.
Program.cs sont concernées.Pour chacune des classes ci-dessous, indique :
private (presque toujours : tous).| Classe | Attributs |
|---|---|
| Personnage | nom, pv, pvMax, niveau |
| CompteBancaire | titulaire, solde |
| LampeConnectee | couleur, intensite (0 à 100), allumee |
| Produit | nom, prix, quantiteEnStock |
Tu écris ce code dans Rider :
class Compte
{
private double solde;
}
// Dans Program.cs :
Compte c = new Compte();
c.solde = 1000;
Console.WriteLine(c.solde);
Rider affiche une erreur. Sans la lire :
public exposent un objet à des affectations absurdes que rien n'empêche.public = accessible partout · private = accessible uniquement dans la classe.private, interface public.private casse temporairement le code appelant — c'est attendu. Il faut maintenant ouvrir des points d'accès contrôlés : c'est l'objet des chapitres 3 et 4.On a fermé la porte. Maintenant, il faut une serrure et une clé : un moyen de lire et d'écrire ces attributs privés depuis l'extérieur, mais en gardant le contrôle. La solution la plus classique, qu'on rencontre dans tous les langages objet (Java, PHP, Python…), s'appelle les getters et les setters. C'est l'objet du chapitre suivant.