les meilleures pratiques pour le passage de nombreux arguments à la méthode?

Question

Parfois , nous avons à écrire des méthodes qui reçoivent beaucoup beaucoup d'arguments , par exemple :

public void doSomething(Object objA , Object objectB ,Date date1 ,Date date2 ,String str1 ,String str2 )
{
}

Quand je rencontre ce genre de problème , j'ai souvent encapsuler des arguments dans une carte.

Map<Object,Object> params = new HashMap<Object,Object>();
params.put("objA",ObjA) ;

......

public void doSomething(Map<Object,Object> params)
{
 // extracting params 
 Object objA = (Object)params.get("objA");
 ......
 }

Ce n'est pas une bonne pratique , encapsuler params une partie de la carte est totalement une perte de l'efficacité. La bonne chose est , la propre signature , facile d'ajouter d'autres params avec le moins de modification . quelle est la meilleure pratique pour ce genre de problème ?

Answer 1

Dans Efficace Java, Chapitre 7 (les Méthodes), Article 40 (méthode de Conception de signatures soigneusement), Bloch écrit:

Il existe trois techniques pour raccourcir trop longues listes de paramètres:

• saut de la méthode dans plusieurs méthodes qui ne nécessitent qu'un sous-ensemble de paramètres
• créer des classes d'aide pour tenir le groupe de paramètres (généralement statiques catégories de membres)
• adapter le Générateur de modèle de construction de l'objet de l'appel de méthode.

Pour plus de détails, je vous encourage à acheter le livre, il vaut vraiment le coup.

Answer 2

À l'aide d'une carte magique avec des clés de Chaîne est une mauvaise idée. Vous perdez tout moment de la compilation, la vérification, et c'est vraiment pas clair ce que les paramètres requis sont. Vous auriez besoin d'écrire très complet de la documentation à faire pour elle. Vous rappelez-vous dans quelques semaines ce que ces Chaînes sont sans regarder le code? Que faire si vous avez fait une faute de frappe? Utiliser le mauvais type? Vous ne trouverez pas jusqu'à ce que vous exécutez le code.

Au lieu d'utiliser un modèle. Faire une classe qui sera un conteneur pour tous ces paramètres. De cette façon, vous gardez le type de sécurité de Java. Vous pouvez également passer cet objet à d'autres méthodes, de le mettre dans les collections, etc.

Bien sûr, si le jeu de paramètres n'est pas utilisé ailleurs ou sont passés d'un modèle dédié peut-être exagéré. Il y a un équilibre à trouver, afin d'utiliser le sens commun.

Answer 3

Si vous avez de nombreux paramètres facultatifs vous pouvez créer des API fluent: remplacer méthode unique avec la chaîne de méthodes

exportWithParams().datesBetween(date1,date2)
                  .format("xml")
                  .columns("id","name","phone")
                  .table("angry_robots")
                  .invoke();

À l'aide de statique à l'importation, vous pouvez créer intérieure couramment l'Api:

... .datesBetween(from(date1).to(date2)) ...

Answer 4

Il est appelé "Introduire le Paramètre de l'Objet". Si vous vous trouvez en passant même liste de paramètres sur plusieurs endroits, il suffit de créer une classe qui les contient toutes.

XXXParameter param = new XXXParameter(objA, objB, date1, date2, str1, str2);
// ...
doSomething(param);

Même si vous ne trouvez pas vous-même en passant même liste de paramètres si souvent, que facile refactoring va encore améliorer la lisibilité de votre code, ce qui est toujours bon. Si vous regardez votre code 3 mois plus tard, il sera plus facile à comprendre quand vous en avez besoin pour résoudre un bug ou d'ajouter une fonctionnalité.

C'est une philosophie générale de la cours, et puisque vous n'avez pas fourni tous les détails, je ne peux pas vous donner des conseils plus détaillés. :-)

Answer 5

Tout d'abord, je voudrais essayer de revoir la méthode. Si c'est de l'aide que de nombreux paramètres, il peut être trop long de toute façon. Le décomposant permettrait à la fois d'améliorer le code et éventuellement de réduire le nombre de paramètres à chaque méthode. Vous pourriez également être en mesure de revoir l'ensemble de l'opération de sa propre classe. Deuxièmement, je regarde pour les autres cas où je suis en utilisant le même (ou un sur-ensemble) de la même liste de paramètres. Si vous avez plusieurs instances, alors il est probable que les signaux de ces propriétés appartiennent ensemble. Dans ce cas, créez une classe afin de conserver les paramètres et l'utiliser. Enfin, je voudrais évaluer si le nombre de paramètres rend-il la peine de créer une carte objet d'améliorer la lisibilité du code. Je pense que c'est un appel personnel -- il y a une douleur de chaque côté, avec cette solution, et où le trade-off point est peut varier. Pour les six paramètres je n'aurais probablement pas le faire. Pour la 10, je n'aurais probablement (si aucune des autres méthodes d'abord travaillé).