Bonjour/ bonsoir,

Dans le cadre d'une réécriture de code pour apprendre la POO, je me pose la question suivante : comment décidez-vous de donner telle ou telle visibilité (public, protected, private) aux propriétés et méthodes. Autant je comprends bien qu'on puisse protéger les paramètres de connexion à une base de données, autant j'ai du mal pour le restant.
Pour être plus concret, j'écris actuellement une simple classe qui va chercher des infos dans une bdd, et va les afficher par la suite:

 var $data; //    variable servant à l'affichage des résultats
 var $message; // variable servant à l'affichage des différents message à l'intention de l'utilisateur

    function resultByName($name) {

        $nom = !empty($name) ? filter_var($name, FILTER_SANITIZE_STRING) : NULL;
        global $PDO;
        $select = $PDO->prepare('SELECT *
          FROM cpte
          WHERE nom LIKE :name');
        $select->bindValue(':name', $nom, PDO::PARAM_STR);
        try {
            $select->execute();
            $this->data = $select->fetch();
            if (!empty($this->data)) {
                $select->closeCursor();
                return $this->data;
            } else {
                $this->message = 'Impossible d\'afficher ce compte';
            }
        } catch (PDOException $e) {
            header('Location:'.$auth->erreurPage);
        }
    }

Dans cet exemple, puis-je laisser les propriétés telles quelles, ou dois-je les protéger plus (peut-être $data ?)
merci,

salut,

bien que n'étant un expert je te dirais simplement qu'un objet et une chose dont on vois rien de l'extérieur ou presque (tous ce qui est public).
Hors les autres (objets, fonctions etc du code) n'ont pas besoin de savoir comment il est fait, en mettant $data en public cela impose qu'elle soit toujours accessible et donc tu ne peu pas réellement savoir ce qu'elle contient (tu peut faire echo $monobjet->data avant d'avoir utilisé $monobjet->resultByName('truc'); et la c'est le drame )

avec une méthode retournant $data tu peux éviter ce cas (en retournant proprement false et ou un message d'erreur).

il y a aussi le cas que tu indique, mais par exemple un objet de connexion au sgbd ou autre.

après private ou protected ça dépend de ce que tu veut faire.
avec private tu ne pourra pas accéder à certaine variable de la classe mère en cas d'héritage

je te conseil cet article sur le sujet qui t'en diras plus que moi

@+

Hello,

De mon coté :

- Toutes les variables sont privées, celles qui doivent être accessible auront un getter, un setter. Ainsi, je peux traiter la valeur passée dans le setter, et travailler la variable dans le getter au besoin.
- Pour les fonctions, ça dépend. Si un fonction dans être accessible depuis l’extérieur, elle sera public. Aussi je ne passe aucune fonction en private, je les mets toujours protected, ainsi si quelqu'un veut hériter de ma classe, il aura accès au panel de fonction.

Exemple :

class TsouinTsouin
{
     private $_a;
     private $_b;

    public function InsertEntry($args, ...)
    {
            $this->CheckData($args,...);
            // insertion
    }

    public function UpdateEntry($args, ...)
    {
            $this->CheckData($args,...);
            // Update
    }

   protected function CheckData($args, ...)
   {
         // test sur les variables...
   }

   public function SetA($a)
   {
          $this->_a = intval($a);
          return $this->_a;
   }

   public function GetA($a)
   {
          return $this->_a;
   }

   public function SetB($b)
   {
          $this->_b = floatval($b);
          return $this->_b;
   }

   public function GetA($a)
   {
          return $this->_b." €";
   }
}

un exemple bidon certe... mais ma méthodologie est là

Bonjour,

Merci pour l'article. D'après ce que j'ai pu en retenir et de ce que tu dis, en peut en gros mettre en private/ protected tout ce dont l'utilisateur n'a pas besoin d'avoir accès (?)
Un deuxième exemple : une méthode pour se connecter à l'application qui sera en public. Et une deuxième qui va vérifier tout le long de la session si c'est la même personne qui est loggée, et qui pourra être en private (?)
merci,

Je répondais en même temps que toi AoSiX En fait, chacun fait un peu à sa sauce, quoi...

En fait, en partie.

Quand tu es seul, tu fais complètement à ta sauce, quand tu bosses en équipe, tu respectes des normes, des conventions de codage, des conventions de nommage, histoire que X ne trouve pas ton code illisible si t'es malade ( C'est la théorie ça, pratiquement, chacun continue de faire à ça sauce, pour mon plus grand malheur ).

Oui, je parlais dans le cas où on est seul... Mais j'imagine qu'en équipe, ça doit être autre chose... Tu t'arraches pas trop les cheveux ?

Je ne peux répondre ...

Hello,

Dans les grands principes de la conception objet on retrouve :
-Encapsulation
-Héritage
-Polymorphisme

Celui qui t'intéresse ici est Encapsulation => La personne utilisant ta classe ne doit pas avoir à savoir comment fonctionne ton code pour pouvoir l'utiliser.
De là tu peux décider ce que tu rends public.
Pour déterminer ce que tu mets en protected, tu utilises un autre principe qui est le principe "ouvert/fermé" :
Les classes doivent être ouvertes à l'extension, mais fermées à la modification.
Donc si tu pense que ta classe sera étendue, voir si tu la faite pour qu'elle soit étendue, tu rends protected les méthodes qui doivent être utilisées par ses enfante.
Enfin pour tout ce qui est private se sont des méthodes dont tu te sers de manière interne à ta classe.
Un bon moyen pour déterminer quelles sont les méthodes qui vont être private c'est d'écrire en français les enchaînements dans ta méthode:

public function explication(){
/*
si utilisateur comprends pas
alors récupérer la question et la reposer //Certainement une fonction private
sinon lui donner un bon point //Ici une autre private
*/
}

Après dans toutes les private que tu vas créer au fur et à mesure, il est possible que tu te rendes compte que tu as besoin de la même fonction dans une autre classe. Dans ce cas, le raccourcis c'est de créer ce qu'on appelle des classes utilitaires. Ces classes sont en fait un amas de méthodes statiques qu'on sait pas où mettre. Un petit conseil, avant de créer une telle classe pose toi la question : "Est ce que je n'ai pas raté un objet que j'aurais du créer ?" car elles sont souvent la preuve d'un défaut de conception du model.

A tout ça tu rajoutes une bonne dose d'expérience et tu obtiens un code objet maintenable et évolutif.

Oui, sûr... Je n'en suis pas encore là... Mais merci pour ces précisions