Object#respond_to?

obj.respond_to?(method_name, include_all=false) -> true or false

Returns boolean· Updated May 30, 2026· Core Classes

reflectionduck-typingmethodsobject

The respond_to? method is a core Ruby reflection method that checks if an object responds to a particular method. It takes a method name (as a Symbol or String) and returns true if the object has a method with that name defined, or false otherwise. This method is fundamental to Ruby’s duck typing philosophy, allowing you to write flexible code that works with any object that “quacks” like a duck.

The method is useful because it lets you ask about behavior before you call it. That is a common pattern in plug-in systems, adapters, and code that works with several object types. It keeps the caller honest about what it expects while still leaving room for objects to expose the behavior in different ways.

Syntax

obj.respond_to?(method_name)
obj.respond_to?(method_name, include_all)

Parameters

Parameter	Type	Default	Description
`method_name`	`Symbol` or `String`	—	The name of the method to check for
`include_all`	`Boolean`	`false`	When `true`, also checks for private methods

Examples

Basic usage

str = "hello"
str.respond_to?(:upcase)
# => true

str.respond_to?(:foobar)
# => false

# Works with strings too
str.respond_to?("downcase")
# => true

Checking for private methods

By default, respond_to? returns false for private methods. Pass true as the second argument to include them. This distinction matters when building tools that introspect objects at runtime, since private methods are part of the object’s full interface even though they are not meant for external callers. The second argument gives you a way to ask “does this method exist at all?” instead of just “is this method part of the public API?”

class User
  def public_method
    "I'm public!"
  end

  private
  def private_method
    "I'm secret!"
  end
end

user = User.new
user.respond_to?(:private_method)
# => false

user.respond_to?(:private_method, true)
# => true

Checking visibility separately is useful when a method exists but should not normally be called from outside the object. The second argument lets you decide whether private behavior should count for the current code path.

Dynamic method dispatch

Use respond_to? before calling methods dynamically to avoid NoMethodError:

def process_object(obj)
  if obj.respond_to?(:to_json)
    puts obj.to_json
  elsif obj.respond_to?(:to_s)
    puts obj.to_s
  else
    puts obj.inspect
  end
end

That pattern keeps dynamic dispatch readable because the branch that handles the object comes immediately after the capability check. You can add another branch for a different API without turning the method into a long case statement.

Common Patterns

Plugin systems

Many gems use respond_to? to check for optional capabilities:

class PluginManager
  def execute_plugins(object)
    plugins.each do |plugin|
      next unless object.respond_to?(plugin.required_method)
      plugin.call(object)
    end
  end
end

Conditional method calls

Build flexible APIs that work with different object types. By checking for a method before calling it, you can accept objects that expose a given interface without requiring them to share a common superclass or module. This is the essence of Ruby duck typing in practice.

def format_output(item)
  formatter = item.respond_to?(:format) ? item : item.to_s
  formatter.format
end

The ternary operator keeps the decision compact, though for longer logic you might prefer an explicit if block. Either way, the key idea is the same: ask the object whether it can handle a message, then decide what to do based on the answer.

Testing for method availability

Check for Ruby version-specific methods. This pattern is common in gems and libraries that support multiple Ruby versions, where newer methods may not exist on older runtimes. The guard clause keeps the code portable without requiring conditional version checks in the Gemfile.

# Only call if available (Ruby 2.5+)
result = str.respond_to?(:delete_suffix) ? str.delete_suffix("!") : str.chomp

Errors

respond_to? never raises an error. It always returns true or false, even for non-existent method names.

That makes it a safe guard for dynamic code paths. If a method is optional, respond_to? is usually the simplest way to check for it without risking a NoMethodError later.