define_method and Metaprogramming

Analogy categoryAnalogies

Metaprogramming is writing code that manipulates code — defining methods, classes, or behavior at runtime rather than typing every line out by hand ahead of time. Ruby is unusually well suited to this because classes and modules remain open and mutable at runtime: you can add methods to a class after it's already been loaded, inspect and modify instance variables from outside their normal accessors, and generate dozens of nearly-identical methods programmatically instead of copy-pasting them. define_method is the workhorse of this style — a private Module method that defines an instance method from a block, where an ordinary def requires a name known at parse time.

🏏

Cricket analogy: A cricket board amending its own rulebook mid-season to add a new dismissal category, rather than needing an entirely new rulebook printed in advance, mirrors how Ruby classes stay open and mutable so methods can be added after the class is already loaded.

define_method versus def

The crucial difference between def and define_method is that define_method takes a block (or a Proc/lambda), and blocks can close over surrounding local variables. This makes it possible to generate a family of methods in a loop, each capturing a different value from the loop, something a literal def cannot express because the method name and body must be fully known as static source text.

🏏

Cricket analogy: Generating five different century_by_X milestone-checker methods in a loop, one per named batsman captured from the loop variable, is only possible with define_method's block closure; a plain def can't have its name determined by a loop variable at runtime.

ruby

class Product
  ATTRIBUTES = %i[name price sku].freeze

  ATTRIBUTES.each do |attribute|
    define_method(attribute) do
      instance_variable_get("@#{attribute}")
    end

    define_method("#{attribute}=") do |value|
      instance_variable_set("@#{attribute}", value)
    end
  end

  def initialize(**attrs)
    attrs.each { |key, value| public_send("#{key}=", value) }
  end
end

product = Product.new(name: "Widget", price: 9.99, sku: "WID-01")
product.price       #=> 9.99
product.price = 12.50
product.price       #=> 12.5

This define_method loop is essentially a hand-rolled version of attr_accessor — and in fact attr_accessor, attr_reader, and attr_writer are themselves implemented using exactly this kind of metaprogramming inside Ruby's own Module class.

class_eval, instance_eval, and dynamic class construction

class_eval (and its alias module_eval) evaluates a block or string of code as though it were written directly inside a class body, letting you reopen and modify a class from outside its original definition — the mechanism behind monkey-patching and many gems' configuration DSLs. instance_eval does the analogous thing for a single object, changing self to that object for the duration of the block, which is how instance-level DSLs (like RSpec's describe/it blocks) evaluate their contents in the context of a specific test object.

🏏

Cricket analogy: A commentator stepping directly onto the pitch to reassign a player's role mid-match, as if editing the team sheet from inside the dugout, mirrors how class_eval lets you modify a class from outside as though writing inside its own body.

ruby

String.class_eval do
  def shout
    upcase + "!"
  end
end

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

config = Object.new
config.instance_eval do
  @timeout = 30
end
config.instance_variable_get(:@timeout)  #=> 30

Monkey-patching built-in classes like String or Array (as in the class_eval example) is powerful but dangerous at scale: it changes behavior globally for every piece of code in the process, including third-party gems, and can silently conflict with another library patching the same method name. Prefer refinements, a dedicated wrapper class, or a well-namespaced module method when the effect doesn't need to be truly global.

define_method defines a method from a block/Proc at runtime, unlike def which requires a static name known at parse time.
Because define_method takes a block, it can close over surrounding local variables, enabling generation of families of related methods in a loop.
attr_accessor and friends are themselves implemented via this same define_method-based metaprogramming inside Ruby's Module class.
class_eval/module_eval reopens a class as if you'd written the code inside its original body, enabling monkey-patching and configuration DSLs.
instance_eval changes self to a specific object for a block, underlying many single-object DSLs like RSpec's example blocks.
Monkey-patching core classes has global effects and can silently conflict with other code; refinements or wrapper classes are often safer.