Pourquoi la quantité de visibilité sur les méthodes et les attributs est-elle importante ?

Question

Pourquoi ne pas laisser toutes les méthodes et tous les attributs accessibles de n'importe où (c'est-à-dire public ) ?

Pouvez-vous donnez-moi un exemple d'un problème que je pourrais rencontrer si je déclarais un attribut en tant que public ?

Answer 1

Pensez à McDonald's comme à un objet. Il y a une méthode publique bien connue pour commander un BigMac.

En interne, il y aura quelques millions d'autres appels pour obtenir les matériaux nécessaires à la fabrication de ce Bigmac. Ils ne veulent pas que vous sachiez comment fonctionne leur chaîne d'approvisionnement, donc tout ce que vous obtenez est le public Gimme_a_BigMac() appel, et ne vous permettra jamais d'accéder à la Slaughter_a_cow() o Buy_potatoes_for_fries() méthodes.

Pour votre propre code, que personne ne verra jamais, allez-y et laissez tout public. Mais si vous créez une bibliothèque destinée à être réutilisée par d'autres, vous devez protéger les détails internes. Ainsi, McDonald's est libre de demander à Scotty de se téléporter sur une galette plutôt que d'appeler une entreprise de camionnage pour livrer la viande par voie terrestre. L'utilisateur final ne voit jamais la différence - il obtient simplement son BigMac. Mais en interne, tout pourrait changer fondamentalement.

Answer 2

Pourquoi ne pas laisser toutes les méthodes et tous les attributs accessibles de partout (c'est-à-dire publics) ?

Parce que c'est beaucoup trop cher .

Chaque méthode publique que je crée doit être soigneusement conçu et ensuite approuvé par une équipe d'architectes, il doit être mis en œuvre à être robuste face à des appelants arbitrairement hostiles ou bogués il faut que ce soit entièrement testé tous les problèmes constatés lors des tests doivent avoir suites de régression ajouté, la méthode doit être documenté la documentation doit être traduit dans au moins douze langues différentes.

Le coût le plus important de tous est cependant : la méthode doit être maintenue, inchangée, pour toujours et à jamais, amen. . Si je décide dans la version suivante que je n'aime pas ce que fait cette méthode, je ne peux pas la changer parce que les clients s'y fient maintenant. Rupture de la rétrocompatibilité d'une méthode publique impose des coûts aux utilisateurs et je répugne à le faire. Vivre avec une mauvaise conception ou implémentation d'une méthode publique impose des coûts élevés aux concepteurs, testeurs et implémenteurs de la prochaine version.

Une méthode publique peut facilement coûter des milliers, voire des dizaines de milliers de dollars. Faites-en une centaine dans une classe et vous obtenez une classe à un million de dollars.

Les méthodes privées n'ont aucun de ces coûts. Dépensez l'argent des actionnaires à bon escient ; rendez tout ce que vous pouvez privé.

Answer 3

Considérez les champs de visibilité comme des cercles de confiance intérieurs.

Prenez l'exemple de vous-même et réfléchissez aux activités qui sont publiques et à celles qui sont privées ou protégées. Il y a un certain nombre de choses que vous ne déléguez à personne pour qu'il les fasse en votre nom. Il y en a qui peuvent être déclenchées par d'autres personnes et d'autres dont l'accès est limité.

De même, en programmation, les scopes vous donnent des outils pour créer différents cercles de confiance. De plus, en rendant les choses privées/protégées, vous avez plus de contrôle sur ce qui se passe. Par exemple, vous pouvez autoriser des plugins tiers qui peuvent étendre une partie de votre code, tout en limitant leur portée.

Ainsi, pour généraliser, les scopes vous donnent un niveau de sécurité supplémentaire et permettent de mieux organiser les choses qu'elles ne le seraient autrement.

Answer 4

Parce que cela viole le concept de encapsulation un principe clé de la POO.

Answer 5

Un risque que vous courez, vous dites ?

<?php

class Foo
{
    /**
     * @var SomeObject
     */
    public $bar;
}

Votre code indique que $bar doit contenir un objet instanceof SomeObject . Cependant, toute personne utilisant votre code pourrait faire

$myFoo->bar = new SomeOtherObject();

... et tout code reposant sur Foo::$bar étant un SomeObject se briserait. Grâce aux récupérateurs, aux régleurs et aux propriétés protégées, vous pouvez faire respecter cette attente :

<?php

class Foo
{
    /**
     * @var SomeObject
     */
    protected $bar;

    public function setBar(SomeObject $bar)
    {
        $this->bar = $bar;
    }
}

Maintenant, vous pouvez être certain que chaque fois que Foo::$bar est défini, ce sera avec un objet instanceof SomeObject .