Meilleures pratiques pour l'utilisation publique, protégée, privée?
Est-il juste de dire que c'est une bonne pratique de tout régler par défaut sur private dès le codage?
Et puis ne le mettez à niveau vers protected si une sous-classe en a besoin, ou public si une autre classe en a besoin?
Réponse courte: Oui
Réponse plus longue:
Oui, mais cela ne doit pas être interprété comme une suggestion de commencer par écrire vos cours avec tout ce qui est privé; cette approche implique la conception de classes en se concentrant sur les détails d'implémentation avant de s'installer sur une interface.
L'un des aspects les plus importants à considérer lors de la conception d'une classe est la manière dont elle sera utilisée; ce qui implique de réfléchir à vos méthodes publiques avant de commencer à penser aux détails privés/d'implémentation.
De plus, cette approche manque généralement de chances de se demander "Comment pourrais-je écrire un test unitaire pour cette classe?" - qui est une question importante à poser même si vous n'écrivez pas réellement de tests unitaires. (Connexes: "Quels sont les principes de conception qui favorisent le code testable?" )
Donc, une fois que vous avez défini l'interface publique, alors c'est une bonne idée de par défaut le reste en privé parce que la plupart de ces éléments seront généralement des détails d'implémentation granuleux qui ne concernent rien en dehors de la classe.
"Et puis ne le mettre à niveau en protégé si une sous-classe en a besoin, ou public si une autre classe en a besoin?"
C'est la mauvaise approche. Au moment de la conception, vous devez savoir quel accès public vous voulez donner. Habituellement, vous donnez l'accès au public parce que c'est tout le but de votre classe. Et vous donnez un accès protégé parce que vous voulez sous-classes pour accéder aux choses. Et vous utilisez le privé pour des choses qui ne sont l'affaire de personne d'autre.
Maintenant, si quelqu'un a besoin d'accéder à des choses auxquelles il ne peut pas accéder, alors vous devriez y réfléchir sérieusement besoin. Ils ne devraient pas besoin cet accès, ou votre conception est incorrecte. Peut-être que votre conception est incorrecte, et quelque chose n'est pas public qui devrait être public, alors vous changez cela. Mais si votre conception est correcte, alors il y a quelque chose qui ne va pas avec le besoin, donc vous corrigez que au lieu d'endommager votre conception.
La clé pour comprendre cet aspect de la programmation orientée objet est le concept de encapsulation de données. L'idée est de rendre une classe plus facile à comprendre en masquant ses détails d'implémentation. Cela s'appelle masquage des données. Ainsi, nous voulons seulement exposer (rendre public) les fonctions qui sont nécessaires pour utiliser la classe. Ces fonctions sont les interface de la classe.
Pensez à une interface comme la roue d'une voiture. Vous décidez dans quelle direction la voiture va en tournant la roue, mais sous les capots il y a des valves rotatives, l'hydraulique, des poulies qui changent la rotation de vos roues, mais vous n'avez pas besoin d'être un ingénieur en mécanique pour conduire une voiture.
La réponse à votre question est donc oui. Vous souhaitez masquer autant de détails sur une classe que possible dans d'autres classes. Comprendre quand quelque chose doit être public, privé ou protégé est facile à apprendre mais difficile à maîtriser.