class << self vs self.method avec Ruby: quoi de mieux?

Question

Ce Ruby Style Guide indique qu'il vaut mieux utiliser self.method_name au lieu de class method_name. Mais pourquoi?

class TestClass 
    # bad 
    class << self 
    def first_method 
     # body omitted 
    end 

    def second_method_etc 
     # body omitted 
    end 
    end 

    # good 
    def self.first_method 
    # body omitted 
    end 

    def self.second_method_etc 
    # body omitted 
    end 
end 

Existe-t-il des problèmes de performances?

Answer 1

class << self est bon à garder toutes vos méthodes de classe dans le même bloc. Si des méthodes sont ajoutées dans def self.method à partir de ce moment-là, il n'y a aucune garantie (autre que la convention et les vœux pieux) qu'il n'y aura pas de méthode de classe supplémentaire cachée plus tard dans le fichier.

def self.method est bon à explicitement indiquant qu'une méthode est une méthode de classe, alors qu'avec class << self vous devez aller chercher le conteneur vous-même.

Lequel de ces est plus important pour vous est une décision subjective et dépend aussi des choses comme combien d'autres personnes travaillent sur le code et quelles sont leurs préférences.

Answer 2

Je suppose qu'ils pensent que self.* est mieux parce que vous pouvez dire avec certitude, c'est une méthode de classe ou d'instance, sans avoir à faire défiler et à explorer cette chaîne class << self.

Answer 3

En général, class << self est utilisé dans metaprogramming pour définir la classe comme soi-même pour une période de temps prolongée. Si je suis en train d'écrire 10 méthodes, je l'utiliser comme ceci:

METHOD_APPENDICES = [1...10] 
class << self 
    METHOD_APPENDICES.each do |n| 
    define_method("method#{n}") { n } 
    end 
end 

Cela créerait 10 méthodes (method1, method2, MÉTHODE3, etc.) qui vient retourner le nombre. Je voudrais utiliser class << self pour la clarté dans ce cas, car en métaprogrammation self est cruciale. Litière self. à l'intérieur il ferait effectivement les choses moins lisible.

Si vous êtes juste définir des méthodes de classe normalement, tenir à self.class_method_name parce que plus les gens sont susceptibles de le comprendre. Pas besoin d'introduire de méta-syntaxe à moins que vous n'attendiez que votre public le comprenne.

Answer 4

Celui que vous voulez. Les deux sont très clairs pour ce que vous faites. Mais je pense à certaines recommandations pour cela.

Quand il sont une seule méthode de classe pour définir, utilisation def self.xxx. Parce que pour définir une seule méthode, le niveau d'indentation croissant devient probablement encombrant.

Quand il sont plus d'une méthode de classe pour définir, utilisation class << self. Parce que l'écriture def self.xxx, def self.yyy et def self.zzz est certainement répétition. Créer une section pour ces méthodes.

Lorsque toutes les méthodes dans une classe sont méthode de classe, vous pouvez utilisermodule avec module_function au lieu de class. Cela vous permet de définir les fonctions du module, utilisez simplement def xxx.

Answer 5

Comme indiqué ci-dessus, les deux styles semblent être équivalents, mais en utilisant class << self permet de marquer les méthodes de classe comme private ou protected.Par exemple:

class UsingDefSelf 
    def self.a; 'public class method'; end 
    private 
    def self.b; 'public class method!'; end 
end 

class UsingSingletonClass 
    class << self 
    def a; 'public class method'; end 
    private 
    def b; 'private class method'; end 
    end 
end 

private affecte uniquement les méthodes d'instance. En utilisant la classe singleton, nous définissons des méthodes d'instance de cette classe, qui se transforment en méthodes de classe de la classe contenant!

Nous pouvons également marquer les méthodes de classe comme private avec def self:

class UsingDefSelf 
    def self.a; 'private class method'; end 
    def self.b; 'private class method!'; end 
    private_class_method :a, :b 
    # In Ruby 2.1 there is an alternative syntax 
    private_class_method def self.c; 'private class method!'; end 
end 

Mais nous ne pouvons pas les marquer comme protected, il n'y a pas protected_class_method. (Cependant, puisque class est la seule instance de sa singletonclass, la méthode de classe privée et les méthodes de classe protégée sont presque identiques, sauf que leur syntaxe d'appel est différente.)

De même, il est moins facile que d'utiliser class << self pour marquer les méthodes de classe private, puisque vous devez lister tous les noms de méthode dans private_class_method ou préfixer private_class_method à chaque définition de méthode de classe privée.

Answer 6

Jusqu'à présent, la question et les réponses ne discutent ces deux options:

class MyClass 
    def self.method_name 
    .. 
    end 
end 

class MyClass 
    class << self 
    def method_name 
     .. 
    end 
    end 
end 

Mais voici une autre option à envisager des méthodes/méthodes/méthodes statiques méthodes de classe/singleton qui opèrent au niveau de la classe (ou tout autre chose vous voulez les appeler):

class MyClass 
    def MyClass.method_name 
    .. 
    end 
end 

Je préfère cette option car elle est plus évidente. La définition de la méthode ressemble à la façon dont elle serait appelée dans votre code, et il est clair qu'elle fonctionne au niveau de la classe.

Je viens aussi d'un fond Python où self est utilisé pour les méthodes d'instance, alors que dans Ruby, self est utilisé pour les méthodes de classe. Cela me perturbe souvent, donc éviter de penser "est une méthode de soi dans Ruby une méthode de classe ou d'instance?" J'utilise def ClassName.methodname.