--001517503d0a06fc4e04a3b9e03e
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 20, 2011 at 11:58 AM, Michael Sokol <mikaa123 / gmail.com> wrote:

> Hello everyone,
>
> What I find fascinating when hacking in Ruby, is that we use one of the
> purest implementation of OOP, and at time we find ourselves tweaking C
> extensions. Thus, the boundary between the two ways of thinking (procedural
> vs OOP) seem very thin, yet it's still fundamentally different.
>
> My question is, what kind of mental model do you use when you program in
> Ruby? How do you think about objects? Do you see them as elements carrying
> with them their own methods, bundled with their data?
>

I really try not to see objects as a collection of functions wrapped around
data. That is how I was taught objects and its a real shame. IMO objects
should be designed around behavior and not data. I try to think of objects
as little people with their own personalities who want to do one thing and
do it really well. I get to be their god, tweak their purpose, and put them
into the system to do their thing.


> How about the flow of the program: Whenever there's a method call, do you
> picture the method to be inside the receiver - just like it would be in a
> real-life object -, or since you know that in the underlying implementation
> the method is stored in the class, you just think about a procedure call
> with a self variable being the receiver?
>

In Ruby you pass a message to an object and get a response. It doesn't
matter if it has a its own method, uses an ancestor's method, or responds
using method_missing. Its not about procedures its about responding to
messages.


> Do you think using the OOP abstraction without knowing the internals can be
> harmful? My case for that (even if I tend not to believe so) would be that
> someone might be tempted to think that during an object instanciation, all
> the instance variables AND methods gets duplicated for this particular
> instance, which isn't the case - yet, that's what the abstraction pushes us
> to believe.
>

Not exactly sure what you are asking for here. You should understand the
object model, but even if you don't I can't see how it harms your ability to
use well designed objects. Design, yes. Use and consume, probably not. But
perhaps I'm not understanding what you are asking.

The book that spoke to me the most about all of this is Object Thinking[1]
by David West. In it he explains how behavior is the key to decomposing your
domain into objects. He also warns against the command and control approach
that is so prevalent in the popular understanding of objects. And there is
also an interesting discussion about objects and immutability in a recent
ADDCasts[2]. They discuss the notion of East-oriented programming where you
move away from assignment and more towards methods/messages. Good luck!

1. http://oreilly.com/catalog/9780735619654
2.
http://addcasts.com/2011/04/21/episode-4-special-guest-james-ladd-talks-to-us-about-running-smalltalk-on-the-jvm-immutability-and-how-to-write-good-oo-code/

--001517503d0a06fc4e04a3b9e03e--