Jeśli na przykład mam tego modelu ActiveRecord:Czy to właściwy sposób na refaktorowanie modeli tłuszczu ActiveRecord?
app/models/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
Czy to dobry sposób byłaby/wyodrębnić logikę z modelu? A może używasz klasy koncernu, klasy usług lub czegoś innego?
jak ktoś powiedział mi dawno temu:
Kod refaktoryzacji nie jest sprawą losowo przeniesienie kodu dookoła.
W swoim przykładzie, że to co robisz dokładnie: przenoszenie kodu do innego pliku
Dlaczego jest tak źle?
Przenoszenie kodu w ten sposób powoduje, że twoja oryginalna klasa jest bardziej skomplikowana, ponieważ logika jest losowo dzielona na kilka innych klas. Oczywiście wygląda lepiej, mniej kodu w jednym pliku jest wizualnie lepsze, ale to wszystko.
Preferuj skład na dziedziczenie. Używanie takich mixinów wymaga "wyczyszczenia" brudnego pokoju przez wyrzucenie bałaganu na sześć oddzielnych szuflad i zamknięcie ich. Jasne, wygląda czysto na powierzchni, ale szuflady śmieciowe utrudniają identyfikację i wdrożenie dekompozycji i ekstrakcji niezbędnych do wyjaśnienia modelu domeny.
Co powinienem zrobić?
Należy zadać sobie pytanie:
Object usługi Wyciąg
sięgam Służby Przedmioty gdy skarga spełnia jeden lub więcej z poniższych kryteriów:
Extract Formularz Przedmioty
Podczas wielokrotnego model może być aktualizowany przez aa składania jednego formularza, możesz utworzyć obiekt formularza.
Umożliwia to umieszczenie całej logiki postaci (konwencje nazw, zatwierdzenia i tym podobne) w jednym miejscu.
Extract Zapytanie Przedmioty
Należy wyodrębnić złożoną zapytań SQL/NoSQL do własnej klasy. Każdy obiekt zapytania jest odpowiedzialny za zwrócenie zestawu wyników w oparciu o kryteria/reguły biznesowe.
Wyciąg Prezenterzy/dekoratorzy
Extract postrzega logikę do prezenterów. Twój model nie powinien zajmować się określoną logiką widoków. Co więcej, umożliwi ci korzystanie z twojego prezentera w wielu widokach.
Dzięki this blogu, aby pomóc mi oddanie ich razem.
Utrzymanie kodu w tej samej klasie przenosi logikę, to nie ekstrakt go.
Zewnętrzna deklaracja wywołania zwrotnego jest myląca i potencjalnie niebezpieczna. Połączenia zwrotne są nadużywane; zmuszanie czytelników do tropienia powiązanych plików jest okrutne.
Nie ma sposobu, aby odpowiedzieć na pytanie; "najlepsze" refaktory zależą od tego, co faktycznie jest refaktoryzowane. Informacje o cyklu życia powinny być jednak oczywiste i precyzyjne.
Obawy, usługi, dekoratorzy, fasady itp. To dobre mechanizmy wspierające refaktoryzację. Nie wiedząc, co jest refaktoryzowane, nie można udzielić sensownej porady dotyczącej tego, co jest "najlepsze".
ten rodzaj separacji jest całkowicie bezcelowy. Jeśli musisz zdekonstruować model, spójrz na obawy. – sevenseacat
@sevenseacat, czy możesz wyjaśnić, dlaczego to nie ma sensu? –
, ponieważ oznacza to, że dzielisz jedną klasę na wiele plików bez żadnego powodu.W ten sposób nie czynisz modelu cieńszym, tylko sprawiasz, że kodowanie jest bardziej skomplikowane. – sevenseacat