2015-12-11 1 views
0

J'ai une classe avec une méthode publique, par exemple:classe Ruby avec méthode publique

class CsvParse 
    def initialize(csv_file) 
    @csv_file = csv_file 
    end 
    def parse 
    ... 
    end 
end 

csv_parse = CsvParse.new('csv_file.csv') 
csv_parse.parse 

Mais la conception de la classe peut être comme ça aussi:

class CsvParse 
    def initialize(csv_file) 
    @csv_file = csv_file 
    parse 
    end 

    private 
    def parse 
    ... 
    end 
end 

csv_parse = CsvParse.new('csv_file.csv') 

Quel est le meilleur entraine toi?

+1

Cela dépend de votre cas d'utilisation. – sawa

+0

Rédigez un test pour votre classe - il révèle généralement des problèmes dans votre conception. (encore mieux: écrivez le [test d'abord] (https://en.wikipedia.org/wiki/Test-driven_development)) – Stefan

Répondre

2

Dans ce cas particulier, il est une méthode d'assistance exposée, qui parse fichier à sa représentation csv

sémantiquement le meilleur appel serait (quoi que ce soit.):

csv_parse = CsvParser.parse 'csv_file.csv' 

Alors, je voudrais aller avec constructeur privé déclarant, ce qui empêche ces objets d'être directement créé:

class CsvParser 
    def initialize ... 
    end 
    private_class_method :new 

    def self.parse *args 
    CsvParser.send(:new, *args).send(:parse) 
    end 
private 
    def parse ... 
end 
+2

Pourquoi appelez-vous '# new' avec' send', puis appelez directement la méthode privée? –

+0

@NickolayKondratenko merci, fixé. – mudasobwa

0

Normalement, vous ne devriez pas commencer l'analyse lors de l'initialisation - ac Selon le principe de la responsabilité unique, une méthode devrait faire une seule chose.

+0

L'un des nombreux contre-exemples de cette revendication est 'Time.parse'. – sawa

+0

@sawa, 'Time.parse' n'est pas un initialiseur ni une méthode d'instance - je parlais du point de vue de' initialize' comme une méthode d'instance – SpeedyWizard

+0

il y a un bon exemple ci-dessus –