2008-12-10 7 views
3

I ont un projet ASP.NET, dans lequel j'ai un procédé avec 10 variables locales. Cette méthode appelle environ 10 autres méthodes. 3 des méthodes appelées ont besoin de toutes les variables. Est-il considéré comme une bonne pratique de transformer toutes ces variables dans les membres mondiaux, et ils n'ont pas passé en tant que paramètres?élément global par rapport à la transmission de paramètres

Répondre

3

créer une structure au lieu et passer la structure au lieu de passer ces 10 paramètres

Ex:

public struct user 
{ 
    public string FirstName; 
    public string LastName; 
    public string zilionotherproperties; 
    public bool SearchByLastNameOnly; 
    public datetime date1; 
} 
+4

Cela devrait être une classe, pas une structure. Et si c'était * une structure, elle devrait être immuable, sinon vous demandez beaucoup de douleur. Oh, et ce devrait être des propriétés, pas des champs - mais je suis d'accord avec l'approche globale (passer un objet pour l'état). –

+1

+1 pour tous les commentaires de Marc. –

+0

Je me demande si le regroupement de paramètres dans une classe à plus grande échelle (disons une API avec environ 50 méthodes) est le choix le plus sage ou pas, est-ce bon s'il y a beaucoup de méthodes avec beaucoup de paramètres? –

2

Eh bien, cela dépend entièrement de ce que vous entendez par « membres globaux ».

Si, étant donné que vous écrivez une application ASP.NET, vous voulez dire les valeurs de cache à base de l'application de la session /, il dépend. Il y a des implications sur les performances, vous devriez donc mesurer pour voir si cela a un impact sur votre application.

Si vous voulez dire les variables statiques, alors non. Statique est par application, et donc pour tous les utilisateurs de votre application web, et pas seulement une seule personne. Discussion statique est pas une bonne idée non plus comme un seul utilisateur peut flotter entre les fils de son vivant dans l'application.

4

Est-ce que ces variables se rapportent les uns aux autres, que ce soit tous ou peut-être dans quelques groupes? Si oui, encapsulez-les dans un type. Vous pouvez donc avoir la moitié de vos variables relatives à un utilisateur, et la moitié liée à une opération demandée - et soudainement votre méthode prenant 10 variables ne prend que 2.

Rendre les choses globales est presque toujours la mauvaise solution.

8

Si vous voulez passer l'état complexe autour, emballez-le dans un objet - à savoir

public class Foo { 
    public string Key {get;set;} 
    public decimal Quantity {get;set;} 
    // etc 
} 

Et ont les méthodes acceptent cet objet comme argument. Ensuite, il vous suffit de créer une instance de ceci et de la transmettre.

Global est un grand non-non; ASP.NET est fortement threaded - ce serait un cauchemar. L'état de chaque demande est possible, mais un peu brouillon.

2

Si vous avez des méthodes qui agissent sur vraiment ne un grand nombre de variables, telles que vous mentionnez, vous pouvez également envisager de concevoir une classe qui a pour but d'agir comme un conteneur de données. Une fois rempli, vous pouvez passer la classe aux fonctions qui nécessitent des données au lieu de dix paramètres. Je ne me souviens pas de l'exemple exact, mais dans le livre "Framework Design Guidelines" de Microsoft, ils décrivent explicitement un scénario comme le vôtre ainsi que la façon dont ils ont suivi la même approche dans le .NET Framework. En outre, si vous avez besoin de transmettre autant de paramètres, prenez du recul et assurez-vous que le code en question n'a pas besoin d'être refactorisé. Il y a des cas légitimes où beaucoup de données est nécessaire par une méthode, mais j'utiliser les signatures de méthode longues comme un signe que je dois regarder à l'intérieur de la méthode pour vous assurer qu'il ne fait que ce qu'il doit.

1

Juste être sûr d'être conscient de la boxe. Si vous passez 10 types de référence, cela dépend de vos préférences personnelles. Cependant, si vous transmettez 10 types de valeur, si vous les déclarez comme variables membres dans une classe, elles seront encadrées, puis devront être décapsulées par le destinataire.Si vous les laissez confinées en tant que variables locales dans la pile de méthodes (en passant en tant que paramètres), elles resteront purement sur la pile, plutôt que d'être encapsulées dans le tas.

1

Pour un refactoring purement mécanique, l'emballage des valeurs ensemble (comme suggéré) est probablement la meilleure solution. Cependant, vous disposez d'une grande série de méthodes dépendantes, chacune d'entre elles agissant sur un état commun (au moins 10 valeurs). Il semble que vous devriez concevoir une classe pour gérer cette opération.

La classe encapsulerait le comportement et l'état pertinent, plutôt que d'être un simple ensemble de propriétés (voir Anemic Domain Model).

Questions connexes