object.inspect / class / is_a? / respond_to?

# Returns a debug-friendly string representation of the object.
object.inspect

# Returns the class of the object.
object.class

# Checks if the object is an instance of the specified class or one of its subclasses.
object.is_a?(ClassName)
object.kind_of?(ClassName)  # Alias for is_a?

# Checks if the object is a direct instance of the specified class (ignores inheritance).
object.instance_of?(ClassName)

# Checks if the object responds to the specified method.
object.respond_to?(:method_name)

# Use class to check the class of an object.
puts 42.class           # Integer
puts "hello".class      # String
puts [1, 2, 3].class    # Array
puts({ a: 1 }.class)    # Hash

# Use is_a? for type checking.
puts 42.is_a?(Integer)  # true
puts 42.is_a?(Numeric)  # true (Integer is a subclass of Numeric)
puts 42.is_a?(String)   # false

# instance_of? does not consider inheritance.
puts 42.instance_of?(Integer)  # true
puts 42.instance_of?(Numeric)  # false (not a direct instance)

# Use respond_to? to check before calling a method.
def safe_convert(obj)
  if obj.respond_to?(:to_i)
    obj.to_i
  else
    0
  end
end

puts safe_convert("42")   # 42
puts safe_convert("abc")  # 0

# Use inspect to display debug information.
data = { name: "Tanaka", scores: [85, 92] }
puts data.inspect  # {:name=>"Tanaka", :scores=>[85, 92]}

In Ruby, everything is an object, and type-checking methods are useful for debugging and polymorphic behavior. Because is_a? considers inheritance, it returns true for parent classes as well — for example, 42.is_a?(Numeric) returns true.

respond_to? is often used together with duck typing, allowing you to decide how to handle an object based on what methods it supports rather than what class it belongs to. Overusing type checks can be considered un-Ruby-like. In many situations, duck typing — checking whether a method is available rather than checking the class — is the preferred approach.