Hey
,
Attention, sujet sensible … Sujet à troll je dirais même.
Voici comment je raisonne : une classe contient les données et on utilise des méthodes pour interroger la classe (on peut faire une analogie avec une boîte). On peut utiliser des données en public mais l'intérêt est exceptionnel. On peut tout mettre en protégé car ça permet à l'utilisateur d'étendre (littéralement et informatiquement parlant) les possibilités de l'application, d'y ajouter des fonctionnalités, d'en réduire … bref de s'approprier le programme. On met les données en privé lorsque c'est réellement dangereux (genre une ressource non partageable, une structure de données complexes à manipuler, voire même partager entre plusieurs attributs — avec des tableaux d'indexes ou ce genre de choses —).
Public, c'est ouvert à tout le monde. Il n'y a aucun contrôle, aucune validité, aucune sécurité sur les données que tu manipules. Rien n'est vérifié. Trivialement, on met un entier à la place d'un tableau, et boom, tu exploses ton programme. Amuses-toi à débugger après …
Protégé, c'est ouvert à la famille de classes (contexte d'héritage). Si tu es hors-contexte, tu utilises les méthodes qui vont faire les vérifications pour toi. Moins de danger. On va même pouvoir faire des vérifications plus fines (comme
x > 0 etc.). Les méthodes peuvent même s'appeler entre-elles histoire d'effectuer des actions plus rapidement. Par exemple, envoyer un mail, la méthode
send peut préparer les protocoles de transport, ouvrir les tubes, écrire dedans, les fermer etc. Pas besoin d'appeler 50 méthodes et d'assigner préalablement 12 attributs.
Privé, contexte très serré, pour les données très sensibles que même l'utilisateur n'a pas le droit d'utiliser dans un contexte d'héritage. Par exemple, si tu as un gestionnaire de pointeurs sur fichiers, c'est très dangereux de laisser l'utilisateur le modifier seul. On va lui proposer tout une gamme de méthodes (en contexte protégé pour une extensibilité par exemple) pour manipuler ce registre.
En gros, selon le niveau critique des données, on n'aura pas la même façon de définir nos contextes d'accessibilités. Soit l'utilisateur peut modifier les données, dans ce cas on est en public, soit l'utilisateur n'a que la façade est ignore le fonctionnement de la classe — ce qui est parfois préférable —, dans ce cas on est en protégé ou privé.
Si PEAR a tout mis en public, c'est sûrement qu'ils utilisaient les classes comme des structures C, c'est à dire une classe de données. On range tout dedans, et hop, aucun contrôle.
C'est effectivement plus rapide, mais moins sécurisé.
De toute façon, c'est comme tout : les
getters sont « longs » (après, ce n'est pas toujours vrai), mais ils ajoutent une abstractions aux applications et permettent une meilleure maintenance, une meilleure réutilisabilité, une meilleure modularité etc. Plus les langages sont abstraits, plus ils respectent les points précédemment cités, mais cela se fait au détriment d'une rapidité, c'est logique …
Toutefois, les langages objets sont conçus pour fonctionner ainsi, et donc, on peut espérer de leur part qu'ils sachent être rapides sur certains points …