Calling an Overridden Monkey-Patched Method in Ruby

By the end of this page, you will understand why super does not call the previous version of a monkey-patched method in the same Ruby class, and how to correctly preserve and call the original method using techniques like alias_method. You will also see safer patterns, common mistakes, and how this works in real Ruby codebases.

In Ruby, monkey patching means reopening a class and changing or replacing its methods. This is powerful, but it also means the new method definition usually replaces the old one.

A common beginner question is: If I redefine a method, can I still call the old version from the new one?

The key idea is:

• super calls a method with the same name in the ancestor chain
• It does not call the method definition that was previously written in the same class
• When you redefine a method in the same class, the old definition is overwritten unless you save it first

So in this case:

class Foo
  def bar
    "Hello"
  end
end

class Foo
  def bar
    super + " World"
  end
end

super will look for bar in Foo's superclass, not for the earlier bar that used to exist in Foo itself.

That is why monkey patching often uses :

Think of a Ruby class like a whiteboard with method names written on it.

If Foo has a method named bar, the whiteboard says:

• bar -> "Hello"

When you reopen the class and define bar again, you erase the old line and write a new one:

• bar -> new implementation

The old writing is gone unless you copied it somewhere first.

Now think of super as walking upstairs to ask a parent class for help. It does not look at what was previously erased and rewritten on the same whiteboard. It only checks parent classes or included modules in the method lookup chain.

So:

• redefining a method in the same class = replacing the current label
• super = ask the next ancestor, not the old version in the same class
• alias_method = make a backup copy before replacing it

Basic pattern with alias_method

class Foo
  def bar
    "Hello"
  end
end

class Foo
  alias_method :bar_without_patch, :bar

  def bar
    bar_without_patch + " World"
  end
end

puts Foo.new.bar
# Hello World

What this does

• alias_method :bar_without_patch, :bar saves the original bar
• The new bar method replaces the old one
• Inside the new bar, you call bar_without_patch

Why super does not work here

class Foo
  def bar
    
  


 
   
     + 
  

Consider this example:

class Foo
  def bar
    "Hello"
  end
end

class Foo
  alias_method :original_bar, :bar

  def bar
    original_bar + " World"
  end
end

result = Foo.new.bar
puts result

Step-by-step

1. Ruby defines class Foo
2. Method bar is created and returns "Hello"
3. Ruby reopens class Foo
4. alias_method :original_bar, :bar creates a second name for the current bar
   • now both bar and original_bar refer to the original implementation
5. A new bar method is defined
   • this replaces the old

Monkey patching with access to the original method appears in several real situations:

Logging and instrumentation

You may want to keep the original behavior but add logging.

class ApiClient
  def fetch
    "data"
  end
end

class ApiClient
  alias_method :original_fetch, :fetch

  def fetch
    puts "Fetching started"
    result = original_fetch
    puts "Fetching finished"
    result
  end
end

Fixing behavior in third-party code

Sometimes a gem has a bug and you need a temporary patch while still using most of its original method.

Adding validation

You can wrap an existing method with extra checks.

class User
  def set_age(age)
    @age = age
  end
end

class User
  alias_method :original_set_age, 

   ()
     ,   age < 
    original_set_age(age)
  

In real Ruby projects, developers usually try to avoid direct monkey patching unless necessary, but when they do use it, they often follow some patterns.

Preserve the original behavior

If the original method still matters, save it before redefining it:

alias_method :original_method_name, :method_name

Prefer prepend for cleaner extension

A common modern pattern is:

module Patch
  def perform(*args)
    puts "before"
    result = super
    puts "after"
    result
  end
end

SomeClass.prepend(Patch)

This is often easier to reason about than alias chains.

Use guard clauses

When wrapping a method, developers often validate inputs early:

def save(data)
  return false if data.nil?
  original_save(data)

Mistake 1: Expecting super to call the old method in the same class

Broken code:

class Foo
  def bar
    "Hello"
  end
end

class Foo
  def bar
    super + " World"
  end
end

Why it fails:

• super looks in ancestors
• it does not call the earlier bar that existed in Foo

Fix:

class Foo
  alias_method :original_bar, :bar

  def bar
    original_bar + " World"
  end
end

Mistake 2: Creating infinite recursion

Broken code:

super vs alias_method vs prepend

Redefining in same class vs subclassing

Quick reference

super

def method_name
  super
end

• Calls the same method in a superclass or prepended/included ancestor
• Does not call the old version of a method redefined in the same class

Save original method before monkey patching

class Foo
  alias_method :original_bar, :bar

  def bar
    original_bar + " World"
  end
end

Important rule

• Alias first, redefine second

With arguments

alias_method :original_greet, :greet

def greet(name)
  original_greet(name) + "!"
end

Cleaner alternative with prepend

Why does super not work when I redefine a method in the same Ruby class?

Because super only looks in the method lookup chain above the current class or module. It does not remember the old method body that was replaced in the same class.

How do I call the original method after monkey patching in Ruby?

Save it first with alias_method, then call the alias inside the new method.

Is alias_method better than super for monkey patching?

For redefining a method in the same class, yes. super is for ancestor methods, while alias_method lets you preserve the original implementation before replacing it.

What is the modern Ruby alternative to alias-based monkey patching?

Module#prepend is often preferred because it works naturally with super and keeps the method lookup chain clearer.

Can monkey patching be dangerous?

Yes. It changes behavior globally for that class in the current process, which can affect unrelated parts of an application.

Should I monkey patch a gem or Ruby core class?

Only when necessary. Prefer safer alternatives like wrappers, subclasses, composition, or prepend if they fit your use case.

Can I monkey patch instance methods and class methods the same way?

Related topics

• Method lookup in Ruby — helps explain where super searches for methods
• Inheritance in Ruby — shows when super is normally used
• Modules in Ruby — important for using include and prepend
• Module#prepend — a cleaner alternative to many monkey patches
• alias_method — the core tool for preserving original methods
• Class reopening in Ruby — the feature that makes monkey patching possible
• Singleton classes and class methods — useful if patching class-level behavior
• Composition vs inheritance — helps decide whether monkey patching is the best design choice