Lorsque vous écrivez une méthode privée, rapport protégé?
Si je suis en train d'écrire une classe, quand dois-je faire une méthode privée, rapport protégé? En d'autres termes, comment je peux savoir à l'avance qu'un programmeur client serait jamais jamais besoin de remplacer une méthode? Dans le cas où elle est quelque chose qui a des considérations externes, comme une connexion de base de données?
- Cela devrait-il être marqués avec le php? Ne semble pas comme il devrait y avoir une différence, mais je ne suis pas familier avec OO trucs en PHP alors peut-être privé v. protégés sont fous-différents en PHP que d'autres langages à objets.
- Je ne suis pas trop familier avec OO en dehors de PHP, donc je n'ai pas envie d'assumer quoi que ce soit. Peut-être que c'est fou différents; je ne sais pas! 🙂
Vous devez vous connecter pour publier un commentaire.
publicetprotectedméthodes forment le "interface" de votre objet,publicpour les développeurs utilisant (déléguer) de votre classe, etprotectedpour les développeurs qui souhaitent étendre les fonctionnalités de votre objet par sous-classement.Noter qu'il n'est pas nécessaire de fournir
protectedméthodes, même si votre classe est sous-classé.Les deux
publicetprotectedinterfaces ont besoin d'être soigneusement pensé, surtout si c'est une API pour être utilisé par les développeurs à l'extérieur de votre contrôle, comme les changements de l'interface peut briser des programmes qui font des hypothèses sur la façon dont cette interface fonctionne.privateméthodes sont purement pour l'auteur de l'objet, et peut être remaniée, modifiés et supprimés à volonté.Je voudrais aller
privatepar défaut, et si vous trouvez que vous avez besoin d'exposer plus de méthodes, d'avoir une attention à penser à la façon dont ils seront utilisés - en particulier si elles sont virtuelles–ce qui se passe si ils sont remplacés complètement à l'arbitraire d'un autre fonction par un autre développeur–votre classe encore du travail? Ensuite, la conception de certains appropriéesprotectedqui sont utiles pour les développeurs de sous-classement de votre objet (si nécessaire), plutôt que d'exposer des fonctions existantes.privatepar défaut est la raison pour laquelle j'ai arrêter l'utilisation de certaines classes. Je ne peux tout simplement pas de les étendre et je ne suis pas prêt à copier-coller.Vous ne pouvez pas. Et vous n'avez pas besoin d'. Ce n'est pas votre travail pour prévoir SI un développeur peut vouloir surcharger une méthode, encore moins comment. Il suffit de supposer qu'il veut et de lui permettre de le faire sans avoir à toucher à votre code. Et pour cette raison, ne pas déclarer les méthodes
privatesi vous n'avez pas à.Si un développeur sent qu'il a besoin de s'adapter certaines fonctionnalités de votre cours, il peut choisir à partir d'un certain nombre d'structurelles et comportementales des motifs de le faire, par exemple, des Décorateurs, des Adaptateurs ou par le sous-classement. À l'aide de ces modèles est bon, parce qu'il encapsule les changements dans le développement propre de la classe et les feuilles de votre propre code intacte. En déclarant les méthodes
private, vous assurez-vous que le développeur de singe avec votre classe. Et ce qui est mauvais.Est un exemple parfait du Zend Framework adaptateur DB. Ils découragent l'utilisation de connexions persistantes et leurs adaptateurs fournissent aucun moyen à cette fin. Mais que faire si vous voulez avoir cette néanmoins et l'adaptateur méthode a été marquée
private(il n'est pas, mais que faire si)? Depuis il n'y a aucun moyen de remplacer la méthode, vous auriez (oui, vous) changement de la carte code de droit dans la classe ou si vous voulez copier & coller le code dans votre propre classe d'adaptateur, de manière efficace la duplication de 99% de la classe juste pour changer un seul appel de fonction. Chaque fois qu'il ya une mise à jour de cette carte, vous perdriez vos changements ou vous ne le ferais pas (dans le cas où vous c&p avais). S'il avait été marquéprotected(comme il est), peut-être vous avez écrit un pConnectAdapter sous-classe.En outre, lorsque le sous-classement, vous êtes effectivement dire la sous-classe est un myclass. Ainsi, vous pouvez vous attendre de la classe dérivée pour avoir les mêmes fonctionnalités que la myclass. Si il existe des fonctionnalités dans le myclass qui ne devraient pas être disponibles dans la sous-classe, la désactivation, conceptuellement, appartient à la sous-classe.
C'est pourquoi je trouve ça beaucoup mieux pratiquer à défaut, toutes les méthodes et propriétés de
protectedla visibilité et la seule marque de ces méthodes (pas de propriétés bien) censé permettre l'interaction avec les élèves de ma classe d'une autre classe ou d'un script commepublic, mais seulement un peu de chosesprivate. De cette façon, je donne au maître d'ouvrage le choix de l'utilisation de ma classe que j'avais l'intention de l'utiliser et la possibilité de l'ajuster. Et si il casse quelque chose dans le processus, il est très probable de sa faute alors, pas la mienne.Mise à jour: depuis que j'ai écrit cela il y a quatre ans je suis venu à la conclusion que le défaut de choses à protégé au lieu de privé conduit souvent à sous-optimal sous-classes. C'est parce que les gens vont commencer à utiliser tout ce que vous avez fournis à titre protégé. Cela signifie que vous avez à considérer l'ensemble de ces méthodes de l'API et ne peut pas les modifier à volonté. En tant que tel, il est préférable de considérer attentivement ce que les extensions de points que vous souhaitez offrir et maintenir le tout privé. Voir http://fabien.potencier.org/article/47/pragmatism-over-theory-protected-vs-private pour un point de vue similaire.
privateouprotected. Si le à ne viennent que lorsque je suis en anticipant les besoins d'un futur programmeur client. Sauf si je veux faire en sorte que certains purement interne à la fonctionnalité de la classe parent ne peut être rompue par un programmeur client -- c'est que ce que vous dites? Sauf si c'est le cas, rendez-vous avecprotected?protectedau lieu deprivate, effectivement, me forçant à écrire un correctif. En tant que programmeur je ne m'attends pas les classes que je sous-classe fonctionne parfaitement si je remplace une méthode protégée sans comprendre ce que je fais. Au lieu de cela, j'ai lu le code, de comprendre ce qui est fait et comment le faire, et de remplacer la méthode en question en conséquence. J'attends la même chose des gens qui travaillent avec mon code. +1En général, je vais commencer au niveau le plus bas. Si vous n'êtes pas sûr de le rendre privé. Puis, au besoin, vous pouvez faire des choses protégé ou public.
L'idée étant, il n'est pas d'une modification de rupture de passer du secteur privé au secteur protégé, mais il pourrait être une modification de rupture aller dans l'autre sens.
Ne pense pas que le privé/protégé/chose publique, comme si un programmeur aurait jamais "besoin" d'une méthode. Il pense que si vous voulez autoriser l'accès.
Si vous pensez qu'ils devraient être autorisés à modifier la DB de la Chaîne de Connexion, puis le rendre public.
J'ai toujours le faire toutes les méthodes
privateen tant que par défaut. C'est de garder l'interface propre et facile à maintenir.Il est beaucoup plus difficile de changer ou de cacher une déjà visible méthode que de faire une méthode privée plus visible. Au moins si vous avez besoin d'être compatible avec l'existant code client.
Si vous ne savez pas supposer qu'ils doivent. Si c'est bien vous (c'est à dire, si vous pensez qu'ils devraient être en mesure d') puis utiliser
protected; sinon, utilisezprivate.Membres privés sont utilisés pour encapsuler le fonctionnement interne de votre classe. Les utiliser pour organiser des données ne vous voulez être en mesure d'accéder. Par exemple, disons que vous avez un champ appelé _name et un getter/setter nommé GetName()/SetName(nom). Peut-être que vous voulez faire de la vérification de la syntaxe du nom avant d'autoriser la SetName pour réussir, sinon vous lancer une exception. En faisant _name privé, vous vous assurez que cette vérification de la syntaxe se produit avant tout un changement de nom peut se produire (sauf si vous vous changer _name dans votre propre classe, dans votre propre code). En rendant protégé, vous êtes en train de dire à tout le potentiel futur héritier de votre classe, "aller de l'avant et le singe avec mon domaine."
En général, protégée est utilisée avec parcimonie et uniquement dans des cas particuliers. Par exemple, vous pourriez avoir un protégé constructeur qui expose certaines de construction supplémentaire de la fonctionnalité classes enfant.
En général, je viens de faire tout
privateet refactoriser quand j'ai besoin de l'appeler à partir d'une classe de base.Sauf quand je me sens paresseux et faire tout ce
protectedqui n'est certainement pas dangereux.