les meilleures pratiques pour refactorisation avec des variables locales

Question

J'ai passé un peu de temps refactorisation mon code C#, et je suis frappé par la taille de mes listes de paramètres OBTIENNENT pour les variables locales, surtout quand vous commencez à recevoir plusieurs niveaux de profondeur et doivent transmettre les variables locales de plus haut dans la pile des appels. Par exemple, j'ai un code assez complexe qui utilise Linq to sql. J'instancie un contexte de données au début d'une procédure et l'utilise tout au long de la procédure. Cependant, après refactoring, je trouve que je passe ce DC à travers toutes mes sous-méthodes, ainsi que diverses autres variables d'état. Une solution, bien sûr, consiste à transformer ces variables locales en variables membres, mais cela rend la classe entière inoffensive, et quand il s'agit d'entrées/sorties asynchrones, cela signifie que les choses sont verrouillées avec des verrous et des mutex. sûr. Quelles sont vos meilleures pratiques en matière d'affacturage en ce qui concerne les variables locales?

Est-ce que vous cédez et en faites des membres? ou transportez-vous autour des bagages d'état? Ou faites-vous autre chose?

EDIT: Je ne suis pas sûr de ce que plus de détails dont vous avez besoin. Je ne veux pas jeter un tas de code, parce que c'est pour illustrer cela que je dois montrer un ensemble de procédures très complexes.

J'ai un certain nombre de variables locales, comme un Linq à Sql DC, diverses étapes de traitement, diverses étapes de mises à jour de beaucoup de données brutes traitées et écrites dans une base de données.

je pensé à créer un contexte d'état et en passant, mais il semble un peu hackish pour moi, même si je suppose que ce précisément ce que l'LINQ to SQL est dc.

Answer 1

Potentiellement, rendez-les membres d'un autre type. Les types imbriqués fonctionnent bien ici aussi. Cela a beaucoup de sens s'ils forment un groupe logique, et vous permettent d'écrire plusieurs méthodes en utilisant le même type.

Au-delà, il faudrait connaître les détails de ce que vous faites pour commenter plus loin, je pense.

Answer 2

Est-ce pas les transformer en membres/variables globales. Ils rendent le raisonnement sur l'application plus difficile, même sans multithreading - et avec lui, comme vous le dites, cela devient un cauchemar total.

Vous pourriez essayer de les effondrer en objets simples et passer ceux qui l'entourent au lieu, si vous remarquez que certains paramètres sont toujours être passés autour des groupes.

Answer 3

Dépend du projet. J'essaie de viser la règle de responsabilité unique qui me permet de refactoriser comme un fou.

Il arrive que je crée des classes de support factices pour tenir les informations que je dois passer autour. Je n'aime pas avoir plus de 1 ou 2 paramètres pour mes méthodes, mais cela dépend de l'importance de l'information et surtout de l'importance du projet.