Si j'ai une grande méthode .NET, je veux savoir s'il est une bonne pratique de la diviser en plusieurs méthodes ou non. Mes préoccupations sont:
1 - Y a-t-il un point créant une méthode si elle ne sera appelée qu'une seule fois? modifier: remplacez global avec l'instance
2 - Si j'appelle une méthode privée de ma classe, j'essaie de ne pas utiliser les variables d'instance. Est-ce une bonne ou une mauvaise pratique? Par exemple:
4 Réponses :
Si un morceau de code va être appelé une fois, il n'est probablement pas une raison de créer la méthode en premier lieu. Cependant, avec cela dit, s'il s'agit d'une méthode privée et qu'il est utilisé comme une fonctionnalité distincte (une préoccupation distincte), alors cela pourrait être une bonne idée de la diviser. Vous voudrez faire cela pour éviter d'avoir une seule méthode énorme. Un exemple serait, si je ne faisais qu'une recherche une fois sur un morceau de code, je voudrais toujours diviser cette recherche car la recherche est une fonction distincte. (C'est un exemple très mauvais. Si quelqu'un en a un meilleur, n'hésitez pas à modifier.
Une variable n'est vraiment globale que si elle est accessible dans l'ensemble du système. Cela dit, je recommande vivement d'éviter les variables mondiales car cela rend très difficile la débogage et de travailler par le code, car les variables ont une portée extrêmement importante. Au lieu de cela, je me concentrerais sur des variables plus localisées et de transmettre les variables qu'une fonction / méthode peut avoir besoin et de retourner des données que la fonction de l'appelant attend. De cette façon, vous gardez vos données plus localisées et, finalement, le code est plus facile à lire et à gérer. Cela n'est pas particulièrement particulier à des méthodes privées ou publiques.
En ce qui concerne votre première question, la réduction de la complexité dans une méthode est une raison suffisante de briser une méthode importante en petits. Les plus petites méthodes sont beaucoup plus faciles à comprendre qu'une seule méthode importante. Si cela est fait correctement, en brisant la méthode dans des unités de travail logiquement cohérentes, de nombreuses petites méthodes sont préférables à une seule méthode importante dans presque tous les cas. Les seules conditions où il pourrait ne pas être est si cela n'a aucune incidence sur votre performance au point où il n'est plus acceptable de cette perspective.
En ce qui concerne la deuxième question, comme @jason souligne, vous utilisez des variables d'instance et non des globaux dans votre classe. Je dirais quelle pratique est préférée dépend du contexte de la méthode. Certes, si la méthode peut être réutilisée dans de nombreux contextes, seuls ceux-ci fonctionnent sur des variables d'instance, il devrait être paramétré. Si vous utilisez uniquement les variables d'instance, vous pouvez choisir de ne pas avoir les paramètres et le refacteur si nécessaire ultérieurement pour une convivialité.
en C #, je préférerais également utiliser l'instance
Le livre "Clean Code" de l'oncle Bob fait un bon travail expliquant des méthodes de rupture. Une règle de base simple est si vous pensez que le code pourrait utiliser un commentaire, il pourrait probablement utiliser une méthode bien nommée.
1 - Y a-t-il un point de créer un méthode si elle ne sera appelée qu'une seule fois?
Oui, il y a beaucoup de raisons de faire cela. La lisibilité est peut-être la plus importante. Si vous pouvez faire une méthode plus lisible et maintenue en le casse, alors par tous les moyens le faire.
Dans mon expérience avec refactoring Code héritée où une méthode est trop longue, il y a de petits morceaux de code qui apparaissent encore et encore. Ce sont généralement les meilleurs endroits pour rechercher des opportunités de refactorisation. La création de méthodes distinctes pour ces pièces peut considérablement diminuer la longueur d'une méthode et, de ce fait, augmenter sa lisibilité.
2 - Si j'appelle une méthode privée De dans ma classe, j'essaie de ne pas utiliser variables d'instance. Est-ce bon ou mauvaise pratique?
Habituellement, plus vous pouvez faire la portée d'une variable. Comme vous, j'ai tendance à utiliser des paramètres chaque fois que possible. Si une méthode a des références uniquement à ses propres paramètres, il devient alors beaucoup plus facile de raisonner sur la méthode, de vérifier son exactitude et de l'utiliser correctement. (Et si une méthode peut le faire et ne pas modifier aucun état, alors qui vous achète un lot des prestations de maintenance.)
Si le but d'une méthode est mieux servi en manipulant les champs d'un objet, cela est parfaitement acceptable, et dans de nombreux cas, inavodable. Mais comme vous l'indiquez, cela est particulièrement vrai avec les méthodes publiques. Lorsque vous refactez une méthode importante en plus petits, je vais rarement, si jamais, accédez aux champs membres directement dans les nouvelles méthodes. Il s'agit principalement d'il suffit de faciliter la raison du comportement du programme.
Lorsque vous refactez de cette manière, assurez-vous de marquer les nouvelles méthodes comme
statique si elles n'accèdent à aucun champ. Cela rendra l'intention explicite.
cote de Clean Code (un excellent livre), une méthode devrait faire une chose et une chose seulement. Si vous faites plusieurs choses dans une méthode, cela signifie probablement que vous devez extraire cette logique dans une méthode distincte. Il est également beaucoup plus facile de suivre le code aussi. Donc, je dirais
question 1: oui cassez-le (séparation de la préoccupation).
Question 2: En général, je pense que c'est une mauvaise pratique d'avoir des variables globales à moins que vous absolument besoin à . En ce qui concerne la question générale de l'utilisation de la propriété privée (variable d'instance) par lui-même sur le public Getter, je ne vois aucun avantage en utilisant le getter. Par exemple, envisagez: contre à un moment donné que vous avez Pour faire référence à la variable d'instance en utilisant ceci . Donc, je ne vois pas d'avantage. Après tout, vous êtes à l'intérieur votre classe, vous avez donc un accès complet aux membres privés.