Mise à jour - Veuillez voir le commentaire ci-dessous qui lie à true explanation of protected
/private
in Ruby. C'était un préjugé profondément ancré de mes jours de Java, en effet. La seule partie importante qui reste à ma réponse est que les méthodes de contrôleur qui ne sont pas des actions ne doivent pas être public
(ou au moins vos routes devraient les protéger).
L'héritage de table unique est un exemple parfait de quand protected
est utile dans le niveau de modèle, car c'est l'une des utilisations les plus courantes de l'héritage là.
Au niveau du contrôleur, méthodes d'assistance définies sur ApplicationController
doit être marqué comme protected
- si elles étaient private
les autres contrôleurs ne seraient pas en mesure d'y accéder, mais si elles sont public
Rails les traiter comme des actions.
Personnellement, je trouve que j'utilise l'héritage de classe plus que beaucoup de mes amis et collègues, même dans les applications Rails. Parce que je l'utilise souvent (et en sortant de mes jours Java), je favorise protected
pour toutes les méthodes d'aide pour donner la liberté à quiconque (généralement moi-même) qui veut prolonger la classe - sauf si je suis vraiment vraiment gêné par un, puis Je le marque private
. :)
Cela fait beaucoup de sens. (Je ne sais pas ce que STI est bien). –
"les méthodes auxiliaires définies sur ApplicationController doivent être marquées comme protégées - si elles étaient privées, les autres contrôleurs ne pourraient pas y accéder" - fyi, ceci est incorrect. Voir l'exemple ici: http://pastie.org/842898. Protégé/privé dans Ruby est sur «soi» et les récepteurs, pas d'héritage. "Notez que, contrairement à des langages tels que Java, l'héritage ne joue absolument aucun rôle dans la détermination de la visibilité de la méthode dans Ruby." - http://weblog.jamisbuck.org/2007/2/23/method-visibility-in-ruby –
Merci, Jordan. Tu as raison. J'ai ajouté une petite note. –