Back to blog

Using Anonymous Classes and Modules in Ruby

One of my favorite aspects of Ruby is that just about everything is an object, even Class and Module. The ability to instantiate "anonymous" classes and modules can give you a great deal of power and help you out in situations where you otherwise might not have a clean solution.

What do Anonymous Things Look Like?

Anonymous classes and modules are just like other classes and modules but a little different. This can be seen best by example:

c = # => #<Class:0x000001009dea80>        # => nil (normally this would be something like "Object") c.class       # => Class         # => #<#<Class:0x000001009dea80>:0x0000010096b3c8> 

So what we did is create an instance of the Class class which is itself a class. Notice that by calling I was able to create an instance of my anonymous class just like I would with a normal one. Now let's take a look at anonymous modules:

m =  c = c.send :include, m  c.ancestors # => [#<Class:0x000001028640b8>, #<Module:0x00000100849030>, Object, Kernel, BasicObject] 

Once you've created an anonymous module you can include it in a class just like you would with a normal module. Anonymous classes and modules behave just like the real thing, they just don't have constant names attached to them!

So now that you can recognize an anonymous class or module, how can you use them in the real world? Is this just a bunch of theoretical nonsense with no practical application?

Keep Specs Fresh With Anonymous Classes

Sometimes it can be difficult to test a module since you don't want to test it tied to a specific implementation. Let's say we have a module that looks like this:

module MyModule   def something?     true    end end 

How can we test it? One solution is to create a "test" class like this:

class MyModuleTest   include MyModule end  it 'should be something' do be_something end 

But there's a problem with that approach: since your test class lives outside the scope of your test, it doesn't get torn down at the end of each test run without manual intervention. So what can we do instead?

let(:fresh_class) do{ include MyModule } end  it 'should do something' do be_something end 

Now we get a pristine class each and every test that we know doesn't have any state baggage. Anonymous classes to the rescue!

Anonymous Modules for Composite Functionality

So now we've seen an example of when anonymous classes can be used, but what about anonymous modules? Well here I'll show you a real piece of code from Grape, my framework for building REST-like APIs.

Grape allows users to define helper methods similar to Sinatra. When a user creates an endpoint for the API, Grape gives them access to all helper methods that were defined in the current context as well as parent contexts. We need a way to store all of the helpers that a user provides and be able to instantly create a module that is a composite of all of the helpers that were defined thus far. It sounds complicated (and it is, a little bit), but here's how we might use it in the end:

class MyAPI < Grape::API   helpers do     def user?; false end   end    namespace :authenticated do     helpers do       def user?; true end     end      get '/' do       user? # => true     end   end    get '/' do     user? # => false   end end 

Now here's the behind-the-scenes code that makes this possible (with some added comments to explain the usage of anonymous modules):

def helpers(mod = nil, &block)   # If a block is given or a argument passed the user is   # *setting* helpers.   if block_given? || mod     # Grab the existing anonymous module for this context     # or create a new one if there isn't one yet.     mod ||= settings.peek[:helpers] ||      # Evaluate the block passed to the `helpers` method     # in the context of our anonymous module.     mod.class_eval &block if block_given?      set(:helpers, mod)    # If no block or argument is passed the user is   # *retrieving* helpers.   else     # Create a fresh anonymous module that isn't     # tied to any existing context.     mod =     settings.stack.each do |s|       # For each context in our stack, include the       # defined helpers in order.       mod.send :include, s[:helpers] if s[:helpers]     end     mod   end end 

Hopefully that isn't too dense to make sense, but anonymous modules allow us to create on-the-fly mixins that are included in the endpoint code to give you access to the helpers you've defined.

Go Forth And Be Nameless

These are just a few examples of the usefulness of anonymous classes and modules; they are powerful tools that can give you more flexibility in designing and testing your Ruby code. Do you have a cool use case for anonymous classes and/or modules? Let me know in the comments!

Image Credit: Astrojunta on Wikipedia

Contact Us

Keep in touch with us

Want to work together? Send us a message? Keep in touch.



Check out our current openings to see if we need your crazy-mad skills right now.

Mobomo, LLC 1900 M Street NW, 3rd Floor, Washington, D.C., United States