So far I’ve talked about how everything was an object in ruby, even classes. I also wrote an article explaining what were the most important steps to follow when trying to understand ruby classes and objects. This wasn’t a bad idea, but it was a rather simplistic view. I think we’re ready to dive into the heart of the object model. Now my objective is not to give you a vague idea about how the ruby object model might work, I want to show you clearly what’s going on behind the scenes. Since I am not a fan of long posts, I have decided to split it in two parts. Here is part 1 :
It’s not that the ruby object model is hard to understand, in fact it is quite simple and coherent, but in order to understand it you’ll need to be concentrated, open minded as well as having a decent understanding of dynamic languages.
A simple case

class MyClass
   def my_instance_method
      "I'm an instance method"
   end
  def MyClass.my_class_method
     "I'm a class method"
  end
end
obj = MyClass.new

Let’s try to understand where does the various elements are located :
What is contained inside the object “obj” ?

1. some flags (we won’t bother about that in this post)
2. instance variables (describe the state of “obj”)
3. a reference to the class, that is : MyClass

Ok fine, but where are the methods? We have to follow the reference to MyClass to find them.
What is contained inside the object “MyClass” ?

1. some flags
2. Instance variables (describe the state of “MyClass”. From “obj” point of view, it’s the class variables, those you reference with @@)
3. a reference to the super class (if any. In this case, it is “Object”)
4. a reference to the class (what? I’m confused now!)
5. Methods (Ahh! Here they are! From “obj” point of view, these are INSTANCE methods)

You said a “reference to the class” ? I beg your pardon?
First of all, let’s not confuse the super class with the reference to the class. The super class is a reference to the ancestor of the current object (in this case, the ancestor is Object), while the reference to the class contains additional information about the current object.
That’s fine, but it doesn’t explain the purpose of that “reference to the class” thing. Aren’t we already inside the class “MyClass” ? Yes, we are. The reason why we need a reference to something else is because we need a place to store the class methods! We have to put them somewhere right? The methods described at point #5 are instance methods. These methods will only exist in the instances you created for class MyClass. They won’t exist in the object MyClass.
That “reference to the class” is in fact a reference to a special class (the pickaxe book call it a meta class) that will hold the methods for the object “MyClass”. Those are what we call class methods (from “obj” point of view at least). It makes a lot of sense when you think about it. Remember, classes are objects… so there’s no reason they cannot have their own methods. if “obj” is able to store it’s methods inside “MyClass”, “MyClass” has to be able to store it’s methods in some other place too : This place is the meta class. You can’t have access to these classes directly, they are completely hidden.
I’ll stop right there for now. In the next (and last) part of this serie, I will talk about the “chain” that ruby follows to find and invokes instance and class methods.