Clars wrote
> In Irv's example below, there's an accessor handler, mGetNumberOfApples,
> that returns info about a specific property.
> If my behavior has, say, 5 properties I want to access, I'd be tempted
> to write an all-round handler like:
>
> on getProperty me, prop
> return value(prop)
> end
...
>
> However, this would seem to be a rash and dangerous balance on the edge
> of broken encapsulation. 'Cuz, I need to know the property name. It just
> seems to me that if I know the handler name, then I'm not ridiculously
> far from knowing the property name.
>
> The alternative would be to write 5 almost identical handlers that
> specifically return property values.
Coincidently, I've been working on this huge complicated project (started
many years ago), and have been thinking about this issue a lot lately.
Originally when I started the project, I was quite strict about using
separate single accessor methods for each property. Its a very complex
project, with literally hundreds of polymorphic object-agents being created
and killed as the project runs. As I have refined the project over time, the
value of encapsulation has been made very very clear.
However, recently it struck me that in many instances, the properties of an
object were often more obvious or apparent from the nature of the object
than the methods to access the property. For example, say there was a
"drinking glass" object. It would be obvious that this object would have
properties relating to what was in it, and how much was in it. In such
cases, it seemed counter-productive to use a specialised accessor method for
each property- since that means other objects need to know the exact method
to access each individual property.
Anyway, to cut a long rambling story short - I've been adopting a strategy
of having 'visible' properties (or 'state descriptors') and 'private'
properties. Visible properties can be accessed via a single interface - a
'mGetState' method which returns a proplist of all the object properties
that are of relevance. For example
on mGetState me --// anyone is entitled to receive this information
StateList = [:]
StateList[#state] = myState
StateList[#thread] = myThread
StateList[#openCount] = myOpenList.count()
StateList[#closedCount] = myClosedList.count()
--
return StateList
end
This method emphasises the descriptive or informative nature of an object's
properties. It is also handy for debugging - when with a single method call,
you can get a list of all relevant 'publicly available' information about an
object.
In the instances where an object needs to know a specific property of
another object in order to make a decision, then I use a specific accessor
method such as
on mGetSpecificProp me --//only objects that know this method get the info
return mySpecificProp
end
In this latter case, it tends to indicate that another object is dependant
upon getting this information (so if you go back to re-work or replace the
code for that object, make sure the accessor method still exists to return
the required information). In this case, the emphasis is on the messaging
interface rather than the internal data structure of the object (which, in
msot cases, should be kept protected from outside interference).
Luke
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
