48 votes

Quand faut-il rendre les méthodes privées?

Il y a beaucoup de moments où je ne suis pas sûr de savoir si une méthode particulière doit être faite privé ou non. Par exemple, je suis en train de construire une classe à droite maintenant, qui est responsable de la génération d'un rapport. Cette classe a un buildReport méthode et plusieurs méthodes de collecte de données nécessaires pour buildReport.

// single public method
// uses a set of helper methods
public buildReport()

// helper methods
private avgSurveyTime()
private fetchVendors()
private fetchSendCounts()
private ...

Je suis demandais si je devais faire de ces méthodes d'aide publique. La seule méthode que j'ai vraiment plan sur l'appel à l'extérieur pour le moment est - buildReport(). Toutefois, il pourrait être utile pour obtenir une liste des fournisseurs avec fetchVendors() etc.

Je vois deux écoles de pensée sur ce point: Vous pouvez toujours exposer aussi peu que possible. (Dans ce cas, beaucoup de mes classes n'aurions qu'une seule méthode publique) OU vous pouvez exposer tout ce que vous pouvez qui pourraient être utiles à l'utilisateur de la classe.

Est-il une bonne règle de base à utiliser pour décider si les méthodes devrait être rendu public/privé?

98voto

ChrisF Points 74295

La seule règle que j'ai suivi est à faire aussi peu que possible du public.

Regardons cela de cette façon. Vous pouvez toujours faire quelque chose de public, plus tard - il ne va pas se casser le code existant. Essayer de faire quelque chose de privé, qui a été le public pourrait bien finir par casser beaucoup de code existant.

Si quelqu'un veut plus de fonctionnalités de votre classe, puis ils peuvent en faire la demande et vous pouvez exposer ce dont ils ont besoin. Les Chances sont qu'ils vous voulez quelque chose qui est subtilement différent de ce que vous avez déjà toute façon, alors vous aurez besoin d'une nouvelle interface.

16voto

Ben James Points 41165

Une technique de guidage utile à suivre consiste à écrire une interface pour votre classe avant de commencer la mise en œuvre. Ensuite, lors de la mise en œuvre, dites-vous qu'une méthode ne figurant pas dans l'interface doit être privée, ou pas du tout dans cette classe.

Si vous ne saviez pas qu'une méthode devait être présente lors de la conception du contrat de la classe, elle ne devrait probablement pas faire partie de son interface publique.

9voto

Patrick Karcher Points 11927
  1. Vous devez vous exposer au monde extérieur que ce que le monde extérieur a vraiment besoin. Il est souvent préférable d'ajouter des fonctionnalités pour les consommateurs de la classe quand il est nécessaire, plutôt qu'au premier. Ces jours-ci la sagesse est d'éviter la pré-ingénierie. (voir YAGNI)

  2. Il peut certainement être acceptable pour le public, d'avoir des méthodes qui sont également utilisées par d'autres fonctions au sein de la classe. Toutefois, cela devrait être considéré comme un mineur mauvaise odeur. Il pourrait être une indication que votre classe est en train d'essayer de faire trop de choses.

Ma conjecture est de laisser vos classes comme ils sont. Ensuite, quand les autres, les plus petits sont les méthodes nécessaires par le monde extérieur, demandez-vous si vous devez séparer vos classes. Si le but de chacune de ces classes pour produire un rapport, alors vous ne devriez pas vous exposer à ces méthodes de cet objet. Au lieu de cela, mettre des "petits" des méthodes dans une même classe d'aide. De cette manière, ils sont disponibles pour le monde extérieur, sans modifier fondamentalement la nature de votre rapport de classes. En bref:

Ne vous contentez pas de le faire parce que vous pensez qu'il pourrait être utile plus tard. Si/Quand la fonctionnalité supplémentaire est nécessaire, revoir votre conception globale et l'adapter aux nouvelles exigences.

5voto

Jeffrey L Whitledge Points 27574

Public et privé méthodes sont très différentes des bêtes. Soyez prudent avant de prendre une méthode publique.

  • Méthodes publiques doit valider l'ensemble de leurs paramètres.
  • Ils doivent être correctement documentées, y compris toutes les exceptions qu'il pourrait jeter.
  • Tous les cas doivent être analysées et delt avec (dans le code ou dans la documentation).
  • Toutes les exigences touchant l'ordre dans lequel les méthodes publiques sont appelées doivent être documentées ou, de préférence, supprimé.
  • État de l'objet exigences doivent également être documentés et validés.
  • Méthodes publiques ne doivent pas changer leur signature ou le comportement d'une manière qui peut sortir d'une application lors du passage d'une version à l'autre.
  • Méthodes publiques peuvent avoir besoin d'être conçu avec un ordonnancement des exigences. (Comme .Net CLS de restrictions.)

Les méthodes privées n'ont aucun de ces limitations.

3voto

Daniel Bingham Points 4900

Si ce n'est pas nécessaire en dehors de la classe, c'est à ce moment-là, faites-le en privé. Si c'est le cas plus tard, vous pouvez le rendre protégé ou public au besoin.

En cas de doute - le rendre privé.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X