Що таке метапрограмування? Плюси та мінуси використання метапрограмування

Якщо ви колись писали has_many :comments у моделі Rails і раптом отримували article.comments, article.comments.create та ще десяток методів безкоштовно, отже, ви вже користувалися метапрограмуванням. Це одна з найпотужніших можливостей Ruby і одна з найсуперечливіших. У цій статті розберемо, що таке метапрограмування, які інструменти для нього є в Ruby, як його використовує Rails і які в нього плюси та мінуси.

Що таке метапрограмування?

Метапрограмування — це написання коду, який пише, читає або змінює інший код (або сам себе). Звичайна програма працює з даними: числами, рядками, користувачами, замовленнями. Метапрограма працює із самою програмою: створює класи й методи, досліджує їхню структуру та змінює їхню поведінку просто під час роботи застосунку.

Розрізняють два основні види метапрограмування:

Під час компіляції: код генерується до запуску програми. Приклади — макроси в C і Rust, шаблони в C++, генератори коду.
Під час виконання: програма змінює себе, поки працює. Це шлях Ruby: класи залишаються відкритими, методи можна визначати на льоту, а в будь-якого об'єкта можна запитати, що він уміє.

Чому Ruby ідеально підходить для метапрограмування

Усе є об'єктом, включно з класами та модулями. Клас — це просто екземпляр Class, тому на ньому можна викликати методи та змінювати його.
Класи відкриті. Будь-який клас, навіть вбудований на кшталт String, можна відкрити знову й додати до нього методи.
Тіло класу — це виконуваний код. attr_accessor :name — не спеціальний синтаксис, а звичайний виклик методу, який виконується в момент визначення класу.
Багатий API рефлексії. Об'єкт може розповісти про свої методи, змінні екземпляра, предків і про те, де визначено кожен метод.

Основні інструменти метапрограмування в Ruby

define_method: динамічне створення методів

Напишімо власну версію 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"

Практичніший приклад — генерація методів-предикатів для статусів замість того, щоб писати кожен вручну:

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

Тепер щоб додати новий статус, достатньо дописати одне слово в масив.

send і public_send: виклик методу за назвою

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

send може викликати й приватні методи, а public_send враховує область видимості. Використовуйте public_send, якщо вам не потрібен саме приватний метод.

method_missing: обробка викликів неіснуючих методів

Коли Ruby не знаходить метод, він викликає method_missing. Перевизначивши його, можна відповідати на методи, які ніколи не були визначені:

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

Тут два правила: завжди викликайте super для імен, які ви не обробляєте (інакше помилки в назвах мовчки повертатимуть nil), і завжди визначайте respond_to_missing?, щоб respond_to? і method(...) працювали коректно.

class_eval, instance_eval і хуки

class_eval виконує код у контексті класу — наприклад, щоб додати до нього методи ззовні.
instance_eval виконує код у контексті конкретного об'єкта. На ньому побудовано багато DSL, наприклад блоки конфігурації.
Хуки на кшталт included, inherited і method_added дозволяють модулю або класу реагувати на підключення, успадкування чи розширення.

Refinements: безпечніший monkey patching

Замість того щоб глобально змінювати вбудований клас, можна обмежити зміну одним файлом або модулем:

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

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

Метапрограмування в Rails

Rails — мабуть, найвідоміший приклад метапрограмування в дії. Подивімося на звичайну модель:

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

Кожен рядок тут — виклик методу, який генерує код:

Атрибути на кшталт title і title= створюються за схемою бази даних. У моделі вони ніде не написані.
has_many :comments додає comments, comments=, comment_ids і багато іншого.
enum генерує published?, published! і скоупи Article.published, Article.draft.
scope :recent визначає метод класу Article.recent.
delegate створює article.author_name.
ActiveSupport::Concern використовує хук included, щоб додавати до моделей колбеки та методи класу.

Завдяки цьому модель завдовжки десять рядків може надавати сотні методів. У цьому сила метапрограмування — і причина, чому новачки часто питають: «Де визначено цей метод?»

Плюси метапрограмування

Менше повторюваного коду (DRY). Один цикл із define_method замінює десятки майже однакових методів.
Виразні DSL. Маршрути в Rails, специфікації в RSpec, міграції та Rake-задачі читаються майже як звичайний англійський текст.
Гнучкість. Код може підлаштовуватися під дані, відомі лише під час виконання: колонки бази, конфігурацію, схему зовнішнього API.
Потужні фреймворки та бібліотеки. ActiveRecord, RSpec, Devise та безліч інших гемів побудовані на метапрограмуванні й заощаджують розробникам величезну кількість часу.
Просте розширення. Додати новий статус, поле чи обробник часто означає дописати один елемент у список, а не писати нові методи.

Мінуси метапрограмування

«Магія» та погана читабельність. Коли методи генеруються на льоту, їх не видно в коді. Новому розробникові спершу треба розібратися в механізмі, а вже потім — у самому класі.
Складна навігація. Пошук def paid? у проєкті нічого не знайде, бо метод створено через define_method. «Перейти до визначення» в IDE теж часто не спрацьовує.
Складне налагодження. Стектрейси проходять через method_missing, блоки define_method і нутрощі бібліотек, через що важче знайти справжнє джерело помилки.
Слабкий статичний аналіз. Лінтери, перевірка типів (Sorbet, RBS/Steep) і автодоповнення не завжди бачать динамічно створені методи.
Продуктивність. method_missing повільніший за звичайний виклик методу, бо Ruby спершу переглядає весь ланцюжок предків. eval із рядками змушений розбирати код під час виконання.
Ризики безпеки. Виклик send або eval з користувацьким введенням може дозволити зловмисникові виконати будь-який метод чи будь-який код.
Конфлікти через monkey patching. Два геми, що додають метод з однаковою назвою до String або Hash, мовчки перезапишуть один одного.

Приклад проблеми з безпекою та її розв'язання:

# Небезпечно: користувач вирішує, який метод викликати
record.send(params[:operation])

# Безпечно: викликати можна лише методи з білого списку
ALLOWED_OPERATIONS = %w[archive publish].freeze

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

Найкращі практики

Починайте зі звичайного коду. Використовуйте метапрограмування лише тоді, коли воно прибирає реальне дублювання, а не тому, що це виглядає ефектно. Добре правило — дочекатися, поки той самий шаблон повториться щонайменше тричі.
Надавайте перевагу define_method замість method_missing. Визначені методи швидші, видимі через рефлексію та простіші в налагодженні.
Якщо використовуєте method_missing, завжди викликайте super і реалізуйте respond_to_missing?.
Використовуйте public_send замість send і ніколи не передавайте в них неперевірене користувацьке введення.
Уникайте eval із рядками. Блоків із define_method і class_eval майже завжди достатньо.
Використовуйте refinements або модулі з prepend замість глобального monkey patching вбудованих класів.
Документуйте згенеровані методи коментарями або YARD-тегами на кшталт @!method, щоб люди та інструменти знали про їхнє існування.
Тримайте магію в бібліотеках та інфраструктурі, а не в бізнес-логіці. Код фреймворку може бути хитрим, код предметної області має бути очевидним.
Покривайте згенеровану поведінку тестами. Легко зламати те, чого не видно.

Ruby також допомагає знаходити «невидимі» методи під час налагодження:

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

Висновок

Метапрограмування — це код, який пише код. У Ruby воно є частиною щоденної роботи: кожен attr_accessor, has_many і validates — це метапрограмування. Воно допомагає прибрати дублювання, будувати елегантні DSL і створювати фреймворки на кшталт Rails. Ціна — менш явний код, складне налагодження та можливі проблеми з продуктивністю й безпекою. Використовуйте метапрограмування свідомо: тоді, коли воно справді робить код простішим для тих, хто його читатиме, а не просто коротшим.