Méthodes protégées et privées dans les Rails

Question

Méthode de visibilité en Ruby (public, protected et private méthodes) a été bien expliqué dans des endroits comme ce blog. Mais en Ruby on Rails, il semble un peu différente de ce qu'elle serait dans une application Ruby en raison de la façon dont le cadre est mis en place. Ainsi, dans les Rails des modèles, des contrôleurs, des aides, des essais, etc., quand est/n'est-il pas approprié d'utiliser protégé ou privé méthodes?

Edit: Merci pour les réponses jusqu'à présent. Je comprends la notion de privé et protégé en Ruby, mais je suis à la recherche de plus pour une explication de la manière typique de ces types de visibilité sont utilisés dans le cadre des différents éléments d'une application Rails (les modèles, les contrôleurs, les aides, les tests). Par exemple, les méthodes de contrôleur sont les méthodes d'action, les méthodes protected dans le contrôleur de l'application sont utilisés pour "helper" qui doivent être accessibles par plusieurs contrôleurs, etc.

Answer 1

Pour les modèles, l'idée est que le public sont les méthodes de l'interface publique de la classe. Les méthodes publiques sont destinés à être utilisés par d'autres objets, tout en protected/private méthodes caché de l'extérieur.

C'est la même pratique que dans d'autres langages orientés objet.

Pour les contrôleurs et les tests, il suffit de faire comme vous s'il vous plaît. À la fois contrôleur et les classes de test ne sont instanciés et appelée par le framework (oui, je sais que vous pouvez obtenir théoriquement le contrôleur de la vue, mais si vous le faites, quelque chose est étrange de toute façon). Car on ne pourra jamais créer ces choses directement, il n'y a rien à "protéger" contre les.

Addendum/Correction: Pour les contrôleurs, vous devez marquer le "helper" méthodes protégées privées, et seulement les actions elles-mêmes devraient être publiques. Le cadre ne sera jamais la route entrants HTTP appels à des actions ou à des méthodes qui ne sont pas publiques, de sorte que vos méthodes d'aide doit être protégé de cette façon.

Pour les aides à ne pas faire de différence, si une méthode est protégé ou privé, car ils sont toujours appelés "directement".

Vous pouvez marquer des trucs protégée dans tous les cas, si cela rend les choses plus facile pour vous de comprendre, bien sûr.

Answer 2

Vous utilisez une méthode privée si vous voulez que personne d'autre, mais self le recours à une méthode. Vous utilisez une méthode protégée si vous voulez quelque chose que l' self and is_a?(self) s peuvent appeler.

Une bonne utilisation de protégé peut-être si vous aviez un "virtuel" initialisation de la méthode.

class Base
    def initialize()
        set_defaults()
        #other stuff
    end

    protected
    def set_defaults()
        # defaults for this type
        @foo = 7
        calculate_and_set_baz()
    end

    private
    def calculate_and_set_baz()
        @baz = "Something that only base classes have like a file handle or resource"
    end
end

class Derived < Base
    protected
    def set_defaults()
        @foo = 13
    end
end

@foo ont des valeurs différentes. et les Dérivés instances ont pas @baz

Mise à jour: Depuis que j'ai écrit, certaines choses ont changé en Ruby 2.0+ Aaron Patterson a une excellente écrire http://tenderlovemaking.com/2012/09/07/protected-methods-and-ruby-2-0.html

Answer 3

La différence entre le protégé et privé est subtile. Si une méthode est protégé, il peut être appelée par n'importe quel instance de la classe de définition ou de ses les sous-classes. Si une méthode est privé, il peut être demandé que dans le cadre de l'objet appelant---il n'est jamais possible d'accéder à un autre objet exemple de méthodes privées directement, même si l'objet est de la même classe en tant qu'appelant. Pour une protection de l' méthodes, ils sont accessibles à partir de les objets de la même classe (ou les enfants).

http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Declaring_Visibility

Answer 4

Vous semblez avoir une bonne idée de la sémantique de la classe de visibilité (public/protected/private) appliqué aux méthodes. Tout ce que je peux offrir est un aperçu rapide de la façon dont je l'implémenter dans mon Rails apps.

- Je mettre en œuvre les méthodes protected dans l'application de base de contrôleur afin qu'ils puissent être appelé par n'importe quel contrôleur via des filtres (par exemple, before_filter :method_foo). De manière similaire, j'définir les méthodes protected pour les modèles que je veux utiliser dans toutes dans un modèle de base qu'ils héritent tous de.

Answer 5

Bien que des actions doivent être les méthodes publiques d'un contrôleur, pas toutes les méthodes publiques sont nécessairement des actions. Vous pouvez utiliser hide_action si vous êtes en utilisant un fourre-tout de la route comme /:controller/:action/:id ou si elle est désactivée (par défaut dans Rails 3) alors que la méthode explicite les itinéraires seront appelés.

Cela peut être utile si vous êtes de passage le contrôleur de l'instance à une autre bibliothèque comme le Liquide moteur de template que vous pouvez fournir une interface publique plutôt que d'avoir à utiliser d'envoyer votre Liquide balises et filtres.