To enable evolution, I'd say.
Encapsulation is quite a barrier to adaptation.
Ideally, the behaviour that "pushes the boundaries" would be refactored into
the class...
Eventually, over time, likely that no "client" object would need to do
direct access to leverage the object.
That's when you have a mature class.
Regards, Gary
----- Original Message -----
From: "Randal L. Schwartz" <mer...@stonehenge.com>
To: "Friedrich Dominicus" <fr...@q-software-solutions.de>
Cc: <Pharo-project@lists.gforge.inria.fr>
Sent: Tuesday, July 26, 2011 4:59 PM
Subject: Re: [Pharo-project] Maybe a brain dead idea
"Friedrich" == Friedrich Dominicus <fr...@q-software-solutions.de>
writes:
Friedrich> I have searched for a way to generate accessor functions with a
program,
Friedrich> but did not understand the implementaion on Pharo but I've
stolen
Friedrich> something from Gemstone Smalltalk (if that is not ok, would
someone
Friedrich> please be so kind to tell me) and there is a method
Why would you want accessors for *all* your instance variables?
Methods provide the public interface for a class's objects. An object
that is just a bag of bits such that any other object can get or set
every one of its instance variables is better represented as a
Dictionary.
You should design your object's interface respecting the needed
protocols, not its internal design. Bad code smell otherwise.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
