Se per esempio ho questo modello ActiveRecord:È un modo corretto per refactoring modelli di grasso ActiveRecord?
app/modelli/order.rb
class Order < ActiveRecord::Base
# model logic
end
require "lib/someclass.rb"
lib/somelass.rb
class Order
before_save :something
# more logic here
end
è che un buon modo per refactoring/estrai la logica dal modello? O forse usi preoccupazione classe, classe di servizio o qualcos'altro?
Come qualcuno mi ha detto molto tempo fa:
codice refactoring non è una questione di modo casuale movimento del codice intorno.
Nel tuo esempio, che è esattamente quello che stai facendo: spostando il codice in un altro file
Perché è brutto?
Spostando il codice in questo modo, si rende la classe originale più complicata poiché la logica viene suddivisa casualmente in diverse altre classi. Certo, sembra migliore, meno codice in un file è visivamente migliore, ma questo è tutto.
Prefer composizione a ereditarietà. Usare mixini come questo richiede di "pulire" una stanza disordinata scaricando il disordine in sei cassetti della spazzatura separati e sbattendoli. Certo, sembra più pulito in superficie, ma i cassetti spazzatura in realtà rendono più difficile identificare e implementare le scomposizioni e le estrazioni necessarie per chiarire il modello di dominio.
Cosa devo fare allora?
Dovresti chiederti:
oggetto estratto Servizio
raggiungo per il Servizio oggetti quando un'azione soddisfa uno o più di questi criteri:
forma di estratto Oggetti
Quando modello multiplo può essere aggiornato aa singolo modulo di presentazione, potresti voler creare un oggetto modulo.
Questo abilita a mettere tutta la logica del modulo (convenzioni del nome, convalide e così via) in un unico posto.
estratto Query Oggetti
Si dovrebbe estrarre SQL complessa/query NoSQL nella loro classe. Ogni oggetto di query è responsabile della restituzione di un set di risultati in base ai criteri/alle regole aziendali.
Presentatori Extract/Decoratori
estratto vede la logica in presentatori. Il tuo modello non dovrebbe occuparsi della logica delle viste specifiche. Inoltre, ti permetterà di usare il tuo presentatore in più viste.
Grazie a this post sul blog per aiutarmi a mettere insieme questi.
Mantenere il codice nella stessa classe mosse logica, non si estratto esso.
L'esternalizzazione della dichiarazione di richiamata è fuorviante e potenzialmente pericolosa. I callback sono abusati abbastanza; costringere i lettori a dare la caccia ai file correlati è crudele.
Non c'è il generale modo di rispondere alla domanda come richiesto; i "migliori" refactors dipendono da ciò che viene effettivamente rifatto. Le informazioni sul ciclo di vita dovrebbero essere ovvie e precise, comunque.
Preoccupazioni, servizi, decoratori, facciate, ecc. Sono buoni meccanismi che supportano il refactoring. Senza sapere cosa viene rifattorizzato è impossibile fornire un consiglio significativo su ciò che è "il migliore".
questo tipo di separazione è completamente inutile. Se devi decostruire un modello, esamina le preoccupazioni. – sevenseacat
@sevenseacat, puoi spiegare perché è inutile? –
perché significa che stai suddividendo una classe in più file senza alcun motivo.Non stai rendendo il modello più sottile in questo modo, stai solo rendendo più complicata la base di codici con cui lavorare. – sevenseacat