Les droits d'accès et l'encapsulation



Pour terminer notre découverte de la programmation orientée objet, il me reste à vous présenter un concept très important : l'encapsulation. En effet, il y a beaucoup de règles en POO et personne ne vous oblige à les suivre ; elles paraissent parfois lourdes et un peu contraignantes, ce qui fait que certains finissent par mal programmer en POO.


Pourtant, s'il y a une règle à suivre en POO, c'est bien l'encapsulation. Cependant, avant de vous expliquer ce que cette règle raconte, je dois vous présenter le principe des droits d'accès.


Les droits d'accès


Vous vous souvenez de ces petits mots que nous avons utilisés devant nos noms de variables et fonctions dans ce chapitre ? Oui, je fais référence à public et  private. Ce sont ce qu'on appelle des droits d'accès : cela permet d'indiquer si l'utilisateur de la classe a le droit d'accéder directement à un élément de la classe ou non.


Il y a trois droits d'accès à connaître :

  • public : tout le monde peut accéder à l'élément ;
  • private : personne (à part la classe elle-même) n'a le droit d'accéder à l'élément ;
  • protected : identique à private, sauf qu'un élément ayant ce droit d'accès dans une classe mère sera accessible aussi dans les classes filles.


Essayons de traduire tout ça en mots français, voulez-vous ?


Reprenons une version simple de notre classe Membre :

<?php

class Membre

{    

    private $pseudo;

    private $email;

    private $signature;

    private $actif;

 

    public function getPseudo()

    {

         

    }

     

    public function setPseudo($nouveauPseudo)

    {

         

    }

}

?>


Ici, vous voyez que les fonctions sont publiques et les variables sont privées. Rien ne nous empêche cependant de faire l'inverse, même si ce n'est vraiment pas conseillé pour les variables, comme nous allons le voir.

Qu'est-ce que cela signifie, concrètement ? Que la personne qui utilise la classe à travers des objets (dans index.php par exemple) peut uniquement accéder à ce qui est public et non à ce qui est privé :

<?php

$membre = new Membre(4);

$membre->setPseudo('M@teo21'); // OK car setPseudo est public

$membre->pseudo = 'M@teo21'; // Interdit car $pseudo est private

?>


C'est donc vous qui définissez avec ces public, private ou protected si l'utilisateur a le droit ou non d'appeler la fonction ou la variable.


Et protected justement, ça correspond à quoi ?


C'est identique à private mais il y a une différence lorsqu'on hérite de la classe. Par exemple, si on définit la variable $email comme protected dans la classe Membre, cela signifie que les classes qui en héritent (comme Admin) auront le droit d'y accéder. Sinon, en private, elles n'auraient pas pu les appeler directement.


L'encapsulation


Pourquoi est-ce qu'on s'embête avec ça ? Et si on mettait tout en public ? On se prendrait moins la tête, non ?


Si tout était public, même les variables membres, n'importe qui pourrait faire :

<?php

$membre = new Membre(4);

$membre->email = 'Portnawak';

?>


Or, « Portnawak » n'est pas une véritable adresse e-mail, je pense que vous serez d'accord avec moi.

Pour éviter qu'on puisse faire n'importe quoi avec ses objets, on a inventé une règle très simple qui s'appelle la règle d'encapsulation. On peut la résumer comme ceci :


Toutes les variables d'une classe doivent toujours être privées ou protégées.


Voilà pourquoi on prend l'habitude de créer des fonctions get et set : cela nous permet de vérifier qu'on ne fait pas n'importe quoi avec les variables, comme définir une adresse e-mail invalide.

Il arrive en revanche que l'on définisse des fonctions membres privées. Ce sont des fonctions internes à la classe que l'utilisateur n'a pas à appeler directement.

Il est en général recommandé d'utiliser plutôt protected que private, surtout si vous pensez hériter de la classe. En effet, leur fonctionnement est le même mais protected est plus souple si vous avez un jour des classes filles.


Le but de l'encapsulation est de masquer à la personne qui utilise la classe son fonctionnement interne. Quand vous créez un objet, vous ne devez pas avoir à vous soucier des variables qu'il contient, de la façon dont celles-ci sont agencées, etc. Vous êtes juste une personne qui appuie sur des boutons pour effectuer des actions sur l'objet (à ce propos, revoyez mes schémas du début du chapitre). Vous devez donc passer par des fonctions pour modifier vos objets.


Pour forcer l'utilisateur à « appuyer sur les boutons » plutôt que de « toucher aux fioles chimiques dangereuses qu'il ne comprend pas », on utilise les droits d'accès. Ainsi, les fonctions sont pour la plupart publiques (sauf celles qui servent au fonctionnement interne de la classe) et les variables sont toujours privées ou protégées pour que l'utilisateur ne puisse pas mettre n'importe quoi à l'intérieur.


En résumé

   

  • La programmation orientée objet est une autre façon de concevoir son code. Elle permet de concevoir les éléments de son site comme des objets à qui l'on donne des ordres et qui sont capables de modifier leur état.
  • La classe est le modèle à partir duquel on peut créer plusieurs objets.
  • Une classe est constituée de variables membres et de fonctions membres. Les fonctions modifient l'état des variables membres.
  • Le constructeur (nommé __construct()) est une fonction appelée par PHP lorsqu'on crée un objet basé sur la classe. De même pour __destruct(), appelée lors de la suppression de l'objet.
  • Une classe peut hériter d'une autre classe pour récupérer toutes ses propriétés et rajouter de nouvelles fonctionnalités spéciales.
  • On oblige le programmeur qui utilise la classe à passer par des fonctions pour modifier l'objet. C'est le principe d'encapsulation.

Créé avec HelpNDoc Personal Edition: Ne laissez pas les utilisateurs non autorisés consulter vos PDF : découvrez comment définir des mots de passe