At 16:19 -0700 2001_08_16, Colin Kettenacker wrote:
> > > I think the key issue is:
>> > No matter how convoluted you make the structure, to avoid having a
>> > "getter" method in the qtObject, you will either wrap the
>> slider-code
>> > inside the main qtObject, or accept passing data from one object and
>> > to another at some point.
>>
>> yes. how indeed do you have these objects function reasonably and
>> efficiently unless they can communicate?
>>
>
>Quick interjection...
>
>I don't think the issue is whether objects can pass data or not... Surely
>they must otherwise there would be no communication between any of your
>objects. I think the issue is should they pass private data to another
>object via a getter method.
So is it better to provide data to another object, than to request
data from it?
in the qtObject example there are two objects, the "video" and the slider.
They each possess state-data.
The video has data about time and rate and more
The slider has data about position and user-actions.
If we were to "data-abstract" the communication between the two
objects, we could - as an exercise - make some extra objects that
were "communication-carriers", and these would be passed between the
two objects. Imagine a click-object being passed from the slider to
the video, and a time- or state object being passed to the slider.
Anyway, I believe this example is really too simple to illustrate the
benefits of such a concept, after all the slider has an integer
positional data, which could expressed as a floating percent, to
deliver to the video, and the video state is equally primitive.
We could try to follow a convention without "getters", and set up the
structure so that the objects "sends" data to each other.
I still think the "aggregate" model, with the video as a "main"
meta-object potentially possessing a slider subObject, is a robust
model.
The video "tells" the slider where it is, and the slider tells the
video where it is being dragged, or otherwise manipulated.
I think that an exercise built over some MultiUser system, might
better show the benefits of the data-abstractions, described in the
article. I am just finishing a system, that "uploads" "creative" data
from a projector to a server, using getNetText and ftpXtra. This is a
"classic" system with flat data being passed in given formats, and it
would be exciting to rethink this system with the MultiUserXtra
sending "objects" back and forth, as described in the ATM example.
>Some people argue that this is perfectly acceptable because you have not
>tried to access the private data directly (i.e.: objectA.pPrivateData) but
>instead used a getter method to access it. But what's the difference?
The difference is that one is public and the other is private, and
the difference is that using a method rather than prodding directly
into the objects property, respects its implementation hiding.
The object has the "capability" to provide some information, that is
relevant, and this capability is expressed as the presence of a
method in the public interface. Accessing a property directly looses
focus of the "capability", and assumes, that the information is
available as a property, which is updated at any given time.
> You
>are simply making private data public.
No. You are providing "some" data when requested through a public
method; different.
> The question then becomes "Why does
>object "A" need this data?".
<and the answer may be>
>You have not done complete object
>encapsulation. Instead keep your object's private data private and move the
>task needed into object "A" or redesign your objects so that this does not
>happen.
This seems to be the focus.
Jakob
[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!]