> but he is saying that you should not get data from an object. if you
> do that is accessing the data and is verboten. correct?
Incorrect. As I mentioned before he is saying access private data is a
no-no. Even in his ATM example he is showing data exchanging between
objects, it's just that none of it is private.
>
> I don't have any problem understanding object properties, accessors,
> encapsulation or any of that stuff. I use it all the time. I was
> trying to figure out how to apply what he was discussing to a basic
> example like this. if you end up putting the slider code inside the
> QTBehavior it starts to become almost like procedural code. you have
> this large bunch of code that becomes difficult to maintain & that has
> everything in it including the kitchen sink. what is the point?
>
At the risk of repeating myself again... What is the real task required
here? Answer: The slider needs to know where to position itself. Do we need
to bundle this functionality into the QT object? Well I guess you could but
we have already decided earlier to make the slider it's own object, and more
to the point make it reusable so that it can work with other media types as
well. You seem to be having a problem with this Al so I got to ask you...
What was wrong with allowing the QT object to relate it's elapsed time as a
percent (as was introduced into this thread on Friday I believe). This data
is not private. It is very extensible as it is not tied to one particular
format (i.e.: movieTime). The slider can use it easily and is even unaware
that the object it is interacting with is a QT. This makes the method
extensible so that the scroller could work just as well with a scrolling
bitmap or what ever.
I know I'm repeating myself here but I am unclear as to why you keep raising
this point.
> if you are
> saying that you can get information from an object as long as you do
> not modify it or get it directly
I wouldn't say that you couldn't modify it... Just so long as it is not
private data.
> and you can pass information to an
> object, as long as what you are passing does not correspond to an
> actual property of an object, then I definitely understand.
That is correct.
> the problem has been the statements in the Java article
> about absolutely no accessor functions and if you need any you should
> be including the accessing method in the object. or at least that is
> the way I read the article.
I think the problem is a matter of semantics... I believe that by accessor
methods we simply mean a method that gets or set another objects properties.
By contrast, a method that returns data that is not private to an object is
*not* classified as an accessor method. I do not know if this is a universal
truth but it certainly seems to be the definition for this thread at least.
Ahhh, Irv agrees (Though I said it first in an earlier post last week:)...
Irv wrote:
> And yes, I think you've got it about the accessor methods, the
> author's basic claim is that methods that get or set properties
> directly are a bad thing. Again, I think this is an excellent design
> goal.
Al wrote:
> so I guess I just don't get the point of the article.
Well Al, I've tried my best in the last couple of weeks and am still willing
to keep trying. I truly apologies if I have been unclear. I'm still under
the gun with the current project and sometimes my frustration seeps out into
my posts.
Please let me know if I have failed yet again to clarify this for you:(
ck
[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!]
