Was just thinking today, earlier, but at the moment
I’m not reallly thinking, I’m mostly asleep right now,
so probably shouldnt be writing, let alone typing, and
especially not with this much Nightquil chugging though me…
BUT OK!!
TITLE: Class are objects!?!
Here is my question: Does having class variables (@@) and
class methods (MyClass.foo) destroy the whole OO design concept?
I’ve always thought of classes like blueprints, and objects like, well,
objects
made from the blueprints. So thinking of classes as objects themselves
that have :attributes, @@variables, and def methods kind of wrecks
my “blueprint” metaphore.
I know I’m wrong, I probably should have wrote that at the top in
big green letters. I just want to throw this out and see just how many
ways I can be proven wrong so that I can learn and maybe
one of the ways will stick like a wet noodle on the wall of my brain
for long enough that I dont have to ask this question again next week.
What I would really like is a better metaphore for class!
Thanks!
Here is my question: Does having class variables (@@) and
class methods (MyClass.foo) destroy the whole OO design concept?
I’ve always thought of classes like blueprints, and objects like, well, objects
made from the blueprints. So thinking of classes as objects themselves
that have :attributes, @@variables, and def methods kind of wrecks
my “blueprint” metaphore.
In your terms I’d probably say that Classes are Objects that represent a
blueprint for other Objects. All Objects, including Classes, are built
from a Class blueprint. All Objects, including Classes, can have
additional capabilities added to their blueprint, and can get new
capabilities custom made after they leave the factory, too.
And I’d ignore @@vars, what I’ve seen so far suggests it’s the best
thing to do most of the time :>
consider a class as a “blueprint object”… problem solved.
Remember, in OO “everything” is an object. But just because everything
is an object, does not mean they’re the same (or even similar.) A
class is rather different to instances of classes (which we call objects
with a slightly different emphasis) for sure, but if you step away far
enough you can still call them both objects in a more general sense.
So “a class” is-a “object”, but in a more general sense. You can make
the same argument about methods and many other things. To me it’s a
subtle shift of perspective, and indeed more OO than languages where
you don’t have the notion of treating most things as an object…
I’ve always thought of classes like blueprints, and objects like,
well, objects
made from the blueprints. So thinking of classes as objects themselves
that have :attributes, @@variables, and def methods kind of wrecks
my “blueprint” metaphore.
Just expand your model a bit. Think of classes as factories that
build objects according to some blueprint. Every now and then
the factory shuts down to be re-tooled. The machines are updated,
the blueprint is altered, then the factory reopens and produces a
slightly
different object and, as a bonus, all the previously manufactured
objects are magically upgraded to the new version also.
I know I’m wrong, I probably should have wrote that at the top in
big green letters. I just want to throw this out and see just how many
ways I can be proven wrong so that I can learn and maybe
one of the ways will stick like a wet noodle on the wall of my brain
for long enough that I dont have to ask this question again next week.
What I would really like is a better metaphore for class!
A better metaphor for a class is - a class!
More seriously, I believe it’s a good idea to start thinking about
classes as just classes as soon as possible. Or to go even further
and think of classes as “Ruby classes”, “Perl classes”, etc.
Metaphors are good for the initial communication, to create the new
structures in your mind by copying aspects of old ones. As you’ve
discovered, they’re treacherous when it comes to thinking about those
things, though. They limit your thinking to just one dimension of the
subject.
Apart from that, the object factory pattern (as described in the
thread and in the Gang of Four book) is one way to think of classes in
Ruby. Another way to think of classes is to remember ways to
implement them, underneath. A constructor just allocate some memory
for an object, add in a pointer to the set of methods in the class and
the class name, and call the initialize method on the “empty” object.
Every time a method call is done on that object, the Ruby interpreter
search through the list of classes that that object is involved with,
in a prioritized order, and find the implementation to call. That
implementation will be method_missing if nothing else is found.
None of these are “complete” per se. It’s still best to just remember
that Ruby classes are Ruby classes, and should be thought of as Ruby
classes. That way, you’ll never go wrong - you just may learn more
abour Ruby classes…
made from the blueprints. So thinking of classes as objects themselves
that have :attributes, @@variables, and def methods kind of wrecks
my “blueprint” metaphore.
I agree with Ross that class variables are best avoided, though one
does need to recognize them of course. In my view they cut a weird
path across what would otherwise be very clear scoping rules.
As for classes as objects: one way to think of it is that classes have
both a kind of “official” status and a kind of “civilian” status.
Sort of the way both parents and their children all have Social
Security numbers (in the US, that is), even though in their
parent/child relationship they play different roles from each other.
Or the way everyone is really at the same level when it comes to
medical needs, whatever else they do in society.
Classes have a special role in Ruby “society”: they are responsible
for bootstrapping other objects into existence. But they are also
members of that society (i.e., objects themselves); so they can
receive messages, own their own instance variables, etc.
If you ignore class variables (which I try to classes are actually
special-cased in rather few ways.
What I would really like is a better metaphore for class!
Thanks!
Objects generally don’t like to hold their methods themselves, that’s
why they ask for other objects, called classes, to hold them. Those
objects are smart and they gather the burden of methods with other
objects, some of them are called modules, while the others are classes.
Sometimes, an object like to hold a method without help. It wants to do
it itself, alone, as if it was a singleton, the unique object of its
kind in the universe. That’s why those kind of methods are called
“singleton methods”.
In ruby, even singleton methods are not truly hold by the object itself,
even if all goes as if it was. A singleton method is hold by a special
object whose name is still hard to define (singleton class, eigenclass,
metaclass, etc…).
Take a look at the output from “ri Class” some time (or see class Class - RDoc Documentation). It will either clear
things up or make them more confusing than ever before possible.
kind in the universe. That’s why those kind of methods are called
“singleton methods”.
In ruby, even singleton methods are not truly hold by the object itself,
even if all goes as if it was. A singleton method is hold by a special
object whose name is still hard to define (singleton class, eigenclass,
metaclass, etc…).
(Singleton class was the last term I heard Matz say he was using
The point about objects not holding methods is so important. People
sometimes talk about “adding methods to objects”, and then get tripped
up about method lookup order. It’s more a matter of the object
meandering through classes and modules, in a certain order, trying to
find a match for a message it’s received.
classes are actually