# @var = change to accessor method? Why?

**URL:** <https://www.ruby-forum.com/t/var-change-to-accessor-method-why/127835>\
**Category:** Ruby\
**Created:** [February 1, 2008, 6:54pm UTC](https://www.ruby-forum.com/t/var-change-to-accessor-method-why/127835 "2008-02-01T18:54:44Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![Day](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/dc4da7/32.png) [@Day](https://www.ruby-forum.com/u/Day)\
**Post date:** [February 1, 2008, 6:54pm UTC](https://www.ruby-forum.com/t/var-change-to-accessor-method-why/127835/1 "2008-02-01T18:54:44Z")

</div>

In ZenTest 3.9.0’s release notes  
([http://blog.zenspider.com/archives/2008/01/zentest\_version\_390\_has\_been\_released.html](http://blog.zenspider.com/archives/2008/01/zentest_version_390_has_been_released.html)),  
it says, “Cleaned out nearly every @ and use accessor methods instead.  
You should too.”

My first thought was, “What?” So in a blog comment, I asked about it.  
Here’s that (brief) exchange:  
[http://blog.zenspider.com/archives/2008/01/zentest\_version\_390\_has\_been\_released.html#comments](http://blog.zenspider.com/archives/2008/01/zentest_version_390_has_been_released.html#comments).  
I may still get an answer there, but it occurred to me that wider  
discussion might be better anyway (and he’s probably on this list,  
yes?). I understand, now, that there is a difference and what that  
difference is (I think), but I still don’t see why the latter is  
better.

So… what’s the advantage of changing

class Thing  
attr\_accessor :a

def do\_something(arg)  
@a = arg  
end  
end

to…

class Thing  
attr\_accessor :a

def do\_something(arg)  
self.a = arg  
end  
end

Am I missing some context that’s helpful in understanding this? I’d  
think that it would be more valuable for readability to keep the @var  
assignment since it clues you in to the nature of the variable (vs. a  
class variable, etc.) than… anything else I can come up with. I will  
be the first to admit that, “anything I can come up with,” is a  
pitifully small set of ideas. I’m not trying to say that this idea is  
bad or whatever… I’m wondering what I don’t know. Thanks in advance  
for illumination.

Ben

---

<div class="post-metadata">

**Author:** ![Day](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/dc4da7/32.png) [@Day](https://www.ruby-forum.com/u/Day)\
**Post date:** [February 1, 2008, 7:05pm UTC](https://www.ruby-forum.com/t/var-change-to-accessor-method-why/127835/2 "2008-02-01T19:05:59Z")

</div>

Day wrote:

> to…
> 
> class Thing  
> attr\_accessor :a
> 
> def do\_something(arg)  
> self.a = arg  
> end  
> end

If you ever decide that the setter method should do more than just  
change the  
var (like for example validate the input and then change the var), you  
can  
replace the method created by attr\_accessor with your own. Places where  
you  
directly assign to @a won’t benefit from that change, though.

HTH,  
Sebastian

---

<div class="post-metadata">

**Author:** ![Day](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/dc4da7/32.png) [@Day](https://www.ruby-forum.com/u/Day)\
**Post date:** [February 1, 2008, 7:07pm UTC](https://www.ruby-forum.com/t/var-change-to-accessor-method-why/127835/3 "2008-02-01T19:07:45Z")

</div>

On Feb 1, 2008, at 10:54 AM, Day wrote:

> class Thing  
> attr\_accessor :a
> 
> def do\_something(arg)  
> self.a = arg  
> end  
> end

imagine that you now want to know everywhere @a is set, perhaps  
because you have a bug. you can start greping or simply

def a= value

```
 p caller
 @a = 42

```

end

done.

also, i don’t use ‘self.a’, but via attributes or fatter

class C  
size 42  
end

where ‘size’ is a getter defined thusly

def a \*value  
if value.empty?  
@a  
else  
send ‘a=’, value.first  
end  
end

which eliminates the oh so tiresome self.

another huge advantage if using uniform access is that you can do  
things like

class C  
attributes 'a, ‘b’, ‘c’  
end

p C.new.attributes =\> [‘a’, ‘b’ , ‘c’]

which is to say you can keep track of what state and object is likely  
to contain. making things like serialization trivial to write.

regards.

a @ [http://codeforpeople.com/](http://codeforpeople.com/)

---

<div class="post-metadata">

**Author:** ![Day](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/dc4da7/32.png) [@Day](https://www.ruby-forum.com/u/Day)\
**Post date:** [February 4, 2008, 3:18am UTC](https://www.ruby-forum.com/t/var-change-to-accessor-method-why/127835/4 "2008-02-04T03:18:57Z")

</div>

i’m on your side, ben. i don’t think that using accessor methods for  
every instance variable is advisable.

basicly it’s a 2nd encapsulation of an attribute within an object that  
undermines the encapsulation that comes with oo design.

i think in a good oo design one should think twice for every instance  
variable that gets an accessor. and it’s the privilege of an object’s  
methods to be able to write to instance variables directly.

if one feels the urge to encapsulate an instance variable within an  
object, maybe it’s time to write another class.

g phil

---

<div class="post-metadata">

**Author:** ![Day](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/dc4da7/32.png) [@Day](https://www.ruby-forum.com/u/Day)\
**Post date:** [February 4, 2008, 11:00am UTC](https://www.ruby-forum.com/t/var-change-to-accessor-method-why/127835/5 "2008-02-04T11:00:02Z")

</div>

On Feb 1, 2008, at 10:05 , ara howard wrote:

> which eliminates the oh so tiresome self.

I personally don’t mind the “self”… I only really use it to be  
explicit and sometimes the inconsistency of needing the self on  
assignment vs not on read is slightly annoying.

I don’t mind the self because I love seeing my little message sends  
all over. makes me warm and fuzzy all over. 😛

---

<div class="post-metadata">

**Author:** ![Day](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/dc4da7/32.png) [@Day](https://www.ruby-forum.com/u/Day)\
**Post date:** [February 4, 2008, 10:58am UTC](https://www.ruby-forum.com/t/var-change-to-accessor-method-why/127835/6 "2008-02-04T10:58:13Z")

</div>

On Feb 3, 2008, at 18:18 , Philipp H. wrote:

> basicly it’s a 2nd encapsulation of an attribute within an object that  
> undermines the encapsulation that comes with oo design.

How exactly does making/using an accessor method “undermine the  
encapsulation”?

---

<div class="post-metadata">

**Author:** ![Day](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/dc4da7/32.png) [@Day](https://www.ruby-forum.com/u/Day)\
**Post date:** [February 13, 2008, 8:21am UTC](https://www.ruby-forum.com/t/var-change-to-accessor-method-why/127835/7 "2008-02-13T08:21:09Z")

</div>

Philipp H. wrote:

> accessors are meant to make the instance variables of an object to be  
> accessible from outside. creating accessors for every variable used in  
> an object (in order to get rid of @s) makes every variable accessible  
> from outside the object. therefore the data is not encapsulated any  
> more.

The data is still encapsulated, although the standard attr\_accessor and  
attr\_writer lets everything just pass through. But writing an accessor  
that for example prevents data to be set to certain values isn’t exactly  
a hard task.

But since Ruby has a method to access the instance variables directly  
anyway, the encapsulation is “undermined” even without accessors.

Best regards,

Jari W.

---

<div class="post-metadata">

**Author:** ![Day](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/dc4da7/32.png) [@Day](https://www.ruby-forum.com/u/Day)\
**Post date:** [February 13, 2008, 5:51am UTC](https://www.ruby-forum.com/t/var-change-to-accessor-method-why/127835/8 "2008-02-13T05:51:33Z")

</div>

On Mon, Feb 04, 2008 at 06:57:21PM +0900, Ryan D. wrote:

> On Feb 3, 2008, at 18:18 , Philipp H. wrote:
> 
> > basicly it’s a 2nd encapsulation of an attribute within an object that  
> > undermines the encapsulation that comes with oo design.
> 
> How exactly does making/using an accessor method “undermine the  
> encapsulation”?

what i meant is:

accessors are meant to make the instance variables of an object to be  
accessible from outside. creating accessors for every variable used in  
an object (in order to get rid of @s) makes every variable accessible  
from outside the object. therefore the data is not encapsulated any  
more.

so what you get is the encapsulation of a variable within an object  
and at the same time exposing it to the rest of your system. (of course  
you could set your accessors private, but that’s even more code.)

g phil

---

<div class="post-metadata">

**Author:** ![Day](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/dc4da7/32.png) [@Day](https://www.ruby-forum.com/u/Day)\
**Post date:** [February 13, 2008, 9:53am UTC](https://www.ruby-forum.com/t/var-change-to-accessor-method-why/127835/9 "2008-02-13T09:53:39Z")

</div>

On Feb 12, 2008, at 8:50 PM, Philipp H. wrote:

> accessors are meant to make the instance variables of an object to be  
> accessible from outside. creating accessors for every variable used in  
> an object (in order to get rid of @s) makes every variable accessible  
> from outside the object. therefore the data is not encapsulated any  
> more.

I’m afraid you’re confusing encapsulation with information hiding [0],  
especially as it pertains to inheritance. Both are good tools when  
used in the right context, but they are not the same. You do not  
“break” your code every time you use one of the attr generator  
methods. Instead you provide an interface to some information that  
your class/instance provides. You’re not opening a vault and letting  
everything run crazy/chaotic by providing access to those instance  
variables. Instead, you’re providing a clean and orderly way of  
getting at that data[1].

Providing accessor methods is the only sane way to make your code and  
its subclasses more resilient to change. It allows you to change the  
internals without affecting the subclasses that use that interface.  
Classes that use ivars directly are more brittle and require more work  
to maintain.

From Beck’s Smalltalk Best Practices:

> If you need to code for inheritance, use Indirect Variable Access.  
> Future generations will thank you.
> 
> One warning–do not go half way. If you are going to use direct  
> access, use it for all access.

[0] [http://c2.com/cgi/wiki?EncapsulationIsNotInformationHiding](http://c2.com/cgi/wiki?EncapsulationIsNotInformationHiding)  
[1] As I’ve said before, if it is anywhere in ruby and evaled or  
parsed in any way, I can get my hands on it and manipulate it. If that  
scares or bothers you, you’re using the wrong language.

---

<div class="post-metadata">

**Author:** ![Day](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/dc4da7/32.png) [@Day](https://www.ruby-forum.com/u/Day)\
**Post date:** [February 15, 2008, 6:02pm UTC](https://www.ruby-forum.com/t/var-change-to-accessor-method-why/127835/10 "2008-02-15T18:02:05Z")

</div>

On Wed, Feb 13, 2008 at 1:09 PM, Philipp H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> confusing something. 😉  
> that is in fact a good point. i wasn’t aware of that. and might make me
> 
> I totally agree. But it still makes a difference for what reasons  
> e.g. ‘send’ is used. It’s on thing to use it for some nifty  
> metaprogramming but it’s another to exploit it to access an otherwise  
> (maybe for a good reason) unaccessible object.

This is one of those topics which got me writing again:

[http://talklikeaduck.denhaven2.com/articles/2008/02/15/best-practice-patterns-accessors-and-encapsulation](http://talklikeaduck.denhaven2.com/articles/2008/02/15/best-practice-patterns-accessors-and-encapsulation)

–  
Rick DeNatale

My blog on Ruby  
[http://talklikeaduck.denhaven2.com/](http://talklikeaduck.denhaven2.com/)

---

<div class="post-metadata">

**Author:** ![Day](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/dc4da7/32.png) [@Day](https://www.ruby-forum.com/u/Day)\
**Post date:** [February 13, 2008, 7:10pm UTC](https://www.ruby-forum.com/t/var-change-to-accessor-method-why/127835/11 "2008-02-13T19:10:44Z")

</div>

On Wed, Feb 13, 2008 at 05:51:33PM +0900, Ryan D. wrote:

> > …
> 
> I’m afraid you’re confusing encapsulation with information hiding [0],

i don’t think so, but thank for pointing me to that article. without  
reading it, i would have thought: hm, presumably he is right, i’m  
confusing something. 😉

> …
> 
> Providing accessor methods is the only sane way to make your code and  
> its subclasses more resilient to change. It allows you to change the  
> internals without affecting the subclasses that use that interface.  
> Classes that use ivars directly are more brittle and require more work  
> to maintain.

that is in fact a good point. i wasn’t aware of that. and might make me  
change my mind. could you or anyone else point out a problamtic case  
in few lines of code? just curious.

> > …
> 
> [0] [http://c2.com/cgi/wiki?EncapsulationIsNotInformationHiding](http://c2.com/cgi/wiki?EncapsulationIsNotInformationHiding)  
> [1] As I’ve said before, if it is anywhere in ruby and evaled or parsed  
> in any way, I can get my hands on it and manipulate it. If that scares or  
> bothers you, you’re using the wrong language.

I totally agree. But it still makes a difference for what reasons  
e.g. ‘send’ is used. It’s on thing to use it for some nifty  
metaprogramming but it’s another to exploit it to access an otherwise  
(maybe for a good reason) unaccessible object.

g phil

---

<div class="post-metadata">

**Author:** ![Day](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/dc4da7/32.png) [@Day](https://www.ruby-forum.com/u/Day)\
**Post date:** [February 15, 2008, 9:20pm UTC](https://www.ruby-forum.com/t/var-change-to-accessor-method-why/127835/12 "2008-02-15T21:20:51Z")

</div>

On Feb 15, 2008, at 09:01 , Rick DeNatale wrote:

> This is one of those topics which got me writing again:
> 
> [http://talklikeaduck.denhaven2.com/articles/2008/02/15/best-practice-patterns-accessors-and-encapsulation](http://talklikeaduck.denhaven2.com/articles/2008/02/15/best-practice-patterns-accessors-and-encapsulation)

Nice writeup.

It was also nice to see you referenced in Kent’s book. 🙂