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!]

Reply via email to