Czym jest metaprogramowanie? Zalety i wady korzystania z metaprogramowania

Jeśli kiedykolwiek napisałeś has_many :comments w modelu Rails i nagle dostałeś article.comments, article.comments.create oraz kilkanaście innych metod za darmo, to znaczy, że korzystałeś już z metaprogramowania. To jedna z najpotężniejszych możliwości Ruby i jednocześnie jedna z najbardziej kontrowersyjnych. W tym artykule wyjaśnimy, czym jest metaprogramowanie, jakie narzędzia oferuje do niego Ruby, jak wykorzystuje je Rails oraz jakie są jego zalety i wady.

Czym jest metaprogramowanie?

Metaprogramowanie to pisanie kodu, który pisze, odczytuje lub zmienia inny kod (albo samego siebie). Zwykły program operuje na danych: liczbach, tekstach, użytkownikach, zamówieniach. Metaprogram operuje na samym programie: tworzy klasy i metody, bada ich strukturę i zmienia ich zachowanie w trakcie działania aplikacji.

Wyróżnia się dwa główne rodzaje metaprogramowania:

W czasie kompilacji: kod jest generowany przed uruchomieniem programu. Przykłady to makra w C i Ruście, szablony w C++ oraz generatory kodu.
W czasie wykonania: program zmienia sam siebie podczas działania. To droga Ruby: klasy pozostają otwarte, metody można definiować w locie, a każdy obiekt można zapytać, co potrafi.

Dlaczego Ruby idealnie nadaje się do metaprogramowania

Wszystko jest obiektem, także klasy i moduły. Klasa to po prostu instancja Class, więc można wywoływać na niej metody i ją zmieniać.
Klasy są otwarte. Każdą klasę, nawet wbudowaną, taką jak String, można ponownie otworzyć i dodać do niej metody.
Ciało klasy to wykonywalny kod. attr_accessor :name to nie specjalna składnia, lecz zwykłe wywołanie metody, które wykonuje się w momencie definiowania klasy.
Bogate API refleksji. Obiekt potrafi powiedzieć, jakie ma metody, zmienne instancji, przodków oraz gdzie zdefiniowano każdą metodę.

Główne narzędzia metaprogramowania w Ruby

define_method: dynamiczne tworzenie metod

Napiszmy własną wersję attr_accessor:

module SimpleAttributes
  def simple_attr(*names)
    names.each do |name|
      define_method(name) { instance_variable_get("@#{name}") }
      define_method("#{name}=") { |value| instance_variable_set("@#{name}", value) }
    end
  end
end

class User
  extend SimpleAttributes
  simple_attr :name, :email
end

user = User.new
user.name = "Anna"
puts user.name # => "Anna"

Bardziej praktyczny przykład to generowanie metod-predykatów dla statusów zamiast pisania każdej z nich ręcznie:

class Order
  STATUSES = %w[pending paid shipped cancelled].freeze

  attr_reader :status

  def initialize(status)
    @status = status
  end

  STATUSES.each do |s|
    define_method("#{s}?") { status == s }
  end
end

order = Order.new("paid")
order.paid?    # => true
order.shipped? # => false

Teraz, aby dodać nowy status, wystarczy dopisać jedno słowo do tablicy.

send i public_send: wywołanie metody po nazwie

%w[daily weekly monthly].each do |period|
  report.public_send("generate_#{period}")
end

send potrafi wywoływać także metody prywatne, a public_send respektuje ich widoczność. Używaj public_send, chyba że naprawdę potrzebujesz dostępu do metody prywatnej.

method_missing: obsługa wywołań nieistniejących metod

Gdy Ruby nie znajduje metody, wywołuje method_missing. Nadpisując ją, można odpowiadać na metody, które nigdy nie zostały zdefiniowane:

class Settings
  def initialize(data)
    @data = data
  end

  def method_missing(name, *args)
    key = name.to_s
    return @data[key] if @data.key?(key)

    super
  end

  def respond_to_missing?(name, include_private = false)
    @data.key?(name.to_s) || super
  end
end

settings = Settings.new("host" => "localhost", "port" => 5432)
settings.host               # => "localhost"
settings.respond_to?(:port) # => true

Obowiązują tu dwie zasady: zawsze wywołuj super dla nazw, których nie obsługujesz (w przeciwnym razie literówki będą po cichu zwracać nil), i zawsze definiuj respond_to_missing?, aby respond_to? i method(...) działały poprawnie.

class_eval, instance_eval i hooki

class_eval wykonuje kod w kontekście klasy, na przykład aby dodać do niej metody z zewnątrz.
instance_eval wykonuje kod w kontekście konkretnego obiektu. Opiera się na nim wiele DSL-i, np. bloki konfiguracyjne.
Hooki, takie jak included, inherited i method_added, pozwalają modułowi lub klasie reagować na dołączenie, dziedziczenie lub rozszerzenie.

Refinements: bezpieczniejszy monkey patching

Zamiast globalnie zmieniać wbudowaną klasę, można ograniczyć zmianę do jednego pliku lub modułu:

module StringExtensions
  refine String do
    def shout
      upcase + "!"
    end
  end
end

using StringExtensions
"hello".shout # => "HELLO!"

Metaprogramowanie w Rails

Rails to chyba najbardziej znany przykład metaprogramowania w praktyce. Spójrzmy na zwykły model:

class Article < ApplicationRecord
  belongs_to :author
  has_many :comments, dependent: :destroy

  enum :status, { draft: 0, published: 1, archived: 2 }

  validates :title, presence: true, length: { maximum: 200 }
  scope :recent, -> { order(created_at: :desc) }
  delegate :name, to: :author, prefix: true
end

Każda linia to wywołanie metody, która generuje kod:

Atrybuty, takie jak title i title=, są tworzone na podstawie schematu bazy danych. W modelu nie są nigdzie zapisane.
has_many :comments dodaje comments, comments=, comment_ids i wiele innych.
enum generuje published?, published! oraz scope'y Article.published, Article.draft.
scope :recent definiuje metodę klasy Article.recent.
delegate tworzy article.author_name.
ActiveSupport::Concern używa hooka included, aby dodawać do modeli callbacki i metody klasy.

Dzięki temu model liczący dziesięć linii może udostępniać setki metod. Na tym polega siła metaprogramowania i właśnie dlatego początkujący często pytają: „Gdzie jest zdefiniowana ta metoda?”

Zalety metaprogramowania

Mniej powtarzalnego kodu (DRY). Jedna pętla z define_method zastępuje dziesiątki niemal identycznych metod.
Wyraziste DSL-e. Routing w Rails, specyfikacje w RSpec, migracje i zadania Rake czyta się niemal jak zwykły tekst po angielsku.
Elastyczność. Kod może dopasować się do danych znanych dopiero w czasie wykonania: kolumn bazy, konfiguracji, schematu zewnętrznego API.
Potężne frameworki i biblioteki. ActiveRecord, RSpec, Devise i wiele innych gemów opiera się na metaprogramowaniu i oszczędza programistom ogromne ilości czasu.
Łatwe rozszerzanie. Dodanie nowego statusu, pola czy handlera często oznacza dopisanie jednego elementu do listy, a nie pisanie nowych metod.

Wady metaprogramowania

„Magia” i słaba czytelność. Gdy metody są generowane w locie, nie widać ich w kodzie. Nowy programista musi najpierw zrozumieć mechanizm, a dopiero potem samą klasę.
Trudna nawigacja. Wyszukanie def paid? w projekcie nic nie zwróci, bo metoda została utworzona przez define_method. Funkcja „przejdź do definicji” w IDE też często zawodzi.
Trudniejsze debugowanie. Stack trace'y przechodzą przez method_missing, bloki define_method i wnętrzności bibliotek, przez co trudniej znaleźć prawdziwe źródło błędu.
Słabsza analiza statyczna. Lintery, sprawdzanie typów (Sorbet, RBS/Steep) i autouzupełnianie nie zawsze widzą dynamicznie tworzone metody.
Wydajność. method_missing jest wolniejsze od zwykłego wywołania metody, bo Ruby najpierw przeszukuje cały łańcuch przodków. eval z tekstem musi parsować kod w trakcie działania.
Ryzyko bezpieczeństwa. Wywołanie send lub eval z danymi od użytkownika może pozwolić atakującemu uruchomić dowolną metodę lub dowolny kod.
Konflikty przez monkey patching. Dwa gemy dodające metodę o tej samej nazwie do String lub Hash po cichu nadpiszą się nawzajem.

Przykład problemu z bezpieczeństwem i jego rozwiązanie:

# Niebezpieczne: użytkownik decyduje, która metoda zostanie wywołana
record.send(params[:operation])

# Bezpieczne: można wywołać tylko metody z białej listy
ALLOWED_OPERATIONS = %w[archive publish].freeze

operation = params[:operation]
record.public_send(operation) if ALLOWED_OPERATIONS.include?(operation)

Dobre praktyki

Zaczynaj od zwykłego kodu. Sięgaj po metaprogramowanie tylko wtedy, gdy usuwa realne powtórzenia, a nie dlatego, że wygląda efektownie. Dobra zasada to poczekać, aż ten sam wzorzec powtórzy się co najmniej trzy razy.
Wybieraj define_method zamiast method_missing. Zdefiniowane metody są szybsze, widoczne przez refleksję i łatwiejsze w debugowaniu.
Jeśli używasz method_missing, zawsze wywołuj super i implementuj respond_to_missing?.
Używaj public_send zamiast send i nigdy nie przekazuj do nich niesprawdzonych danych od użytkownika.
Unikaj eval z tekstem. Bloki z define_method i class_eval prawie zawsze wystarczą.
Używaj refinements lub modułów z prepend zamiast globalnego monkey patchingu wbudowanych klas.
Dokumentuj generowane metody komentarzami lub tagami YARD, np. @!method, aby ludzie i narzędzia wiedzieli o ich istnieniu.
Trzymaj magię w bibliotekach i infrastrukturze, a nie w logice biznesowej. Kod frameworka może być sprytny, kod domenowy powinien być oczywisty.
Pokrywaj generowane zachowanie testami. Łatwo zepsuć coś, czego nie widać.

Ruby pomaga też znaleźć „niewidzialne” metody podczas debugowania:

order = Order.new("paid")

order.method(:paid?).source_location # => ["app/models/order.rb", 11]
Order.instance_methods(false)        # => [:status, :pending?, :paid?, ...]
Article.instance_method(:author_name).owner

Podsumowanie

Metaprogramowanie to kod, który pisze kod. W Ruby jest częścią codziennej pracy: każde attr_accessor, has_many i validates to metaprogramowanie. Pomaga usuwać powtórzenia, budować eleganckie DSL-e i tworzyć frameworki takie jak Rails. Ceną jest mniej jawny kod, trudniejsze debugowanie oraz potencjalne problemy z wydajnością i bezpieczeństwem. Korzystaj z metaprogramowania świadomie: wtedy, gdy naprawdę upraszcza kod dla osób, które będą go czytać, a nie tylko go skraca.

Wstecz