2009-05-22 20 views
14

Confessione: utilizzo solo privato e pubblico con visibilità per i miei metodi!Usi mai la visibilità protetta in Rails?

Ho la sensazione che questa sia una brutta cosa. Ma in Rails non sembra essere un problema.

Qualcuno ha un esempio in Rails dove sarebbe un grosso errore non utilizzare la visibilità protetta?

risposta

9

Aggiornamento - Si prega di consultare il commento qui sotto che collega a un true explanation of protected/private in Ruby. Quello era un profondo pregiudizio lasciato dai miei giorni in Java, anzi. L'unica parte importante della mia risposta è che i metodi di controllo che non sono azioni non dovrebbero essere public (o almeno i percorsi dovrebbero proteggerli).

L'ereditarietà tabella singola è un perfetto esempio di quando protected è utile nel livello modello, in quanto è uno degli usi più comuni dell'ereditarietà.

nel livello di controllo, metodi di supporto definiti su ApplicationController deve essere contrassegnato come protected - se fossero private altri controller non sarebbero in grado di accedervi, ma se sono public Rails li tratteranno come azioni.

Personalmente, trovo che uso l'ereditarietà di classe più di molti dei miei amici e colleghi, anche nelle applicazioni Rails. Perché lo uso spesso (e uscendo dai miei giorni Java), preferisco lo protected per tutti i metodi di supporto per dare libertà a chiunque (di solito io stesso) che vuole estendere la classe - a meno che non sia davvero imbarazzante per uno, allora Lo contrassegno private. :)

+0

Questo ha molto senso. (Non sono sicuro di quale sia lo STI). –

+3

"I metodi helper definiti su ApplicationController devono essere contrassegnati come protetti - se fossero privati ​​gli altri controllori non sarebbero in grado di accedervi" - fyi, questo non è corretto. Vedi esempio qui: http://pastie.org/842898. Protetto/privato in Ruby riguarda 'sé' e destinatari, non eredità. "Nota che, a differenza di linguaggi come Java, l'ereditarietà non ha assolutamente alcun ruolo nel determinare la visibilità del metodo in Ruby." - http://weblog.jamisbuck.org/2007/2/23/method-visibility-in-ruby –

+0

Grazie, Jordan. Hai ragione. Ho aggiunto una piccola nota. –

0

ho SingleTableInheritance

persona classe < AR :: Base classe insegnante < persona calss Student < persona

E io uso i metodi protetti di implementare un metodo privato che è comune per studenti e docenti :

class Person < AR::base 
    def self.find(*args) 
    reject_leaves(super(*args)) 
    end 
protected 
    def self.reject_leaves(target) #like a private in Teacher and Student 
    case target 
     when Array target.select{|t| reject_leaves(t)} 
     when Person (target.leave_date < Date.today ? target : nil) 
     else target 
    end 
    end 
end 

Disclaimer: ci sono plugin come act-as-paranoid e altri per implementare la funzione Io uso qui per mostrarti il ​​caso, ma ho un panorama più complesso, che ho semplificato qui per arrivare al punto.

+0

fyi, il tuo esempio sopra non funziona correttamente - puoi chiamare 'Person.reject_leaves (...)' senza problemi. "public/protected/private" in ruby ​​non sono parole chiave: sono invocazioni di metodi su "self" che modificano lo stato di "self". Dal momento che cambi ciò che 'self' è quando fai' def self. reject_leaves' non hai più la configurazione dello stato 'protected'. per ottenere ciò che vuoi, ti serve qualcosa come il secondo esempio ('Prot2') qui: http://pastie.org/842952 –