Что такое метапрограммирование? Плюсы и минусы использования метапрограммирования

Если вы когда-нибудь писали 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. Цена — менее явный код, сложная отладка и возможные проблемы с производительностью и безопасностью. Используйте метапрограммирование осознанно: тогда, когда оно действительно делает код проще для тех, кто будет его читать, а не просто короче.