Lorsque vous écrivez une méthode privée, rapport protégé?

Question

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?

Answer 1

public et protected méthodes forment le "interface" de votre objet, public pour les développeurs utilisant (déléguer) de votre classe, et protected pour les développeurs qui souhaitent étendre les fonctionnalités de votre objet par sous-classement.

Notez qu'il n'est pas nécessaire de fournir de l' protected méthodes, même si votre classe est sous-classé.

Les deux public et protected interfaces 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.

private méthodes sont purement pour l'auteur de l'objet, et peut être remaniée, modifiés et supprimés à volonté.

Je pencherais pour private par 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ées protected qui sont utiles pour les développeurs de sous-classement de votre objet (si nécessaire), plutôt que d'exposer des fonctions existantes.

Answer 2

En d'autres termes, comment je peux savoir en l'avance qu'un programmeur client serait jamais, jamais, jamais besoin de remplacer une méthode?

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 private si 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 méthodes d' private,- vous assurez-vous que le développeur de singe avec votre classe. Et ce qui est mauvais.

Un exemple parfait est 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 si)? Depuis il n'y a aucun moyen de remplacer la méthode, vous (oui, vous) changement de la carte code de droit dans la classe ou si vous voulez copier et de 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 avait). S'il avait été marquée protected (comme il est), peut-être vous avez écrit un pConnectAdapter sous-classe.

En outre, lorsque le sous-classement, vous êtes effectivement dire 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 d' protected 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 comme public, mais seulement un peu de choses private. 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 d'un point de vue semblable.

Answer 3

En 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.

Answer 4

Ne pensons 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.

Answer 5

J'ai toujours le faire à toutes les méthodes, private comme valeur 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.