From: "James Britt (rubydev)" <james@...>
Date: 2002-01-24T10:44:45+09:00
Subject: RE: OOP UI Design


> 
> That is, Ruby lets us start out with an attr_accessor for
> :num_monkeys in class Barrel, just getting and setting a 
> stored value; but if computation should become necessary to
> the task, Ruby lets us define Barrel#num_monkeys and
> Barrel#num_monkeys= as methods more complex than those auto-
> generated by attr_accessor. . .
> 
> . . . Does this address any of your concerns, or am I, like,
> totally missing the point?  =)
> 

I think the issue (possbly raised by Holub) is that, regardless of how
the getter derives the return value, the client becomes dependant on
that value type.  So, if num_monkeys really should return a complex number
rather than an integer, client code breaks when that's changed.

A question to ask is, why is some code asking an object for data?
Wht can't the code tell the object to proces its own data internally?

(What's refered to as "Tell, Don't Ask" by the Prag Prg folks, I believe)

I certainly wouldn't *ban* getters & setters, but trying to avoid them has
help me produce less-coupled code.


James