Passer des hachages au lieu de paramètres de méthode

Question

Je vois que dans Ruby (et typées dynamiquement langues, en général) une pratique très courante est de passer d'une table de hachage, au lieu de déclarer béton paramètres de la méthode. Par exemple, au lieu de déclarer une méthode avec des paramètres et de l'appeler comme ceci:

def my_method(width, height, show_border)
my_method(400, 50, false)

vous pouvez le faire de cette façon:

def my_method(options)
my_method({"width" => 400, "height" => 50, "show_border" => false})

J'aimerais connaître votre opinion à ce sujet. Est-ce une bonne ou une mauvaise pratique, doit-on le faire ou pas? En quoi la situation à l'aide de la validité de cette pratique, et ce quelle situation peut-elle être dangereuse?

Answer 1

Ruby a des paramètres de hachage implicites, vous pouvez donc aussi écrire

 def my_method(options = {}) 

my_method(:width => 400, :height => 50, :show_border => false)
 

et avec Ruby 1.9 et la nouvelle syntaxe de hachage, il peut être

 my_method( width: 400, height: 50, show_border: false )
 

Quand une fonction prend plus de 3-4 paramètres, il est beaucoup plus facile de voir ce qui est quoi, sans compter les positions respectives.

Answer 2

Les deux approches ont leurs propres avantages et inconvénients, lorsque vous utilisez une des options de hachage remplacer les arguments que vous perdre de la clarté dans le code de la définition de la méthode, mais le gain de clarté, chaque fois que vous utilisez la méthode en raison de la pseudo-nommé paramètres créée en utilisant l'une des options de hachage.

Ma règle générale est que si vous avez beaucoup d'arguments pour une méthode (plus de 3 ou 4) ou il y a beaucoup d'arguments facultatifs puis utilisez une des options de hachage sinon utiliser des arguments. Néanmoins, en utilisant une des options de hachage, il est important de toujours inclure un commentaire avec la définition de la méthode décrivant les arguments possibles.

Answer 3

Je dirais que si vous êtes:

1. Ayant plus de 6 paramètres de la méthode
2. En passant les options qui ont certaines obligatoires, d'autres facultatives et certaines avec des valeurs par défaut

Vous auriez probablement souhaitez utiliser une table de hachage. Il est beaucoup plus facile de voir ce que les arguments dire sans avoir besoin de chercher dans la documentation.

Pour ceux d'entre vous disant qu'il est difficile de déterminer quelles sont les options une méthode a, cela signifie simplement que le code est mal documentée. Avec COUR, vous pouvez utiliser l' @option balise pour spécifier les options:

##
# Create a box.
#
# @param [Hash] options The options hash.
# @option options [Numeric] :width The width of the box.
# @option options [Numeric] :height The height of the box.
# @option options [Boolean] :show_border (false) Whether to show a
#   border or not.
def create_box(options={})
  options[:show_border] ||= false
end

Mais dans cet exemple précis, il existe quelques et de paramètres simples, donc je pense que j'irais avec ceci:

##
# Create a box.
#
# @param [Numeric] width The width of the box.
# @param [Numeric] height The height of the box.
# @param [Boolean] show_border Whether to show a border or not.
def create_box(width, height, show_border=false)
end

Answer 4

Je pense que cette méthode de passage de paramètre est beaucoup plus claire quand il y a plus que quelques paramètres ou quand il y a un certain nombre de paramètres optionnels. Il fait essentiellement des appels de méthode manifestement auto-documentés.

Answer 5

Il n'est pas pratique courante dans Ruby à utiliser une table de hachage plutôt que les paramètres formels.

Je pense que c'est la confondre avec le modèle commun de passage d'un hachage comme un paramètre lorsque le paramètre peut prendre un certain nombre de valeurs par exemple, la définition des attributs d'une Fenêtre dans un toolkit graphique.

Si vous avez un certain nombre d'arguments à votre fonction ou méthode alors explicitement de les déclarer et de les transmettre. Vous obtenez les avantages que l'interprète va vérifier que vous avez passé tous les arguments.

Ne pas abuser du langage, à savoir quand l'utiliser et quand ne pas l'utiliser.