OK,
I just read the article. good one BTW, even if I think he's just a
bit, shall I say, opinionated. <grin> but that is fine. so here is his
ATM example:
===========
An object-oriented ATM system just models the earlier problem
statement. Here's the message flow:
The user (Bill) walks up to an ATM, presents his card and PIN, and
requests a withdrawal.
The Teller object asks the server-side Bank_records object, "Is the
person with this card and this PIN legit?"
The Bank_records object comes back with "yes" or "no."
The Teller object asks the Bank_records object for an empty
Withdrawal_slip. (This object will be an instance of some class that
implements the Withdrawal_slip interface, and will be passed from the
Bank_records object to the Teller object by value (using RMI). That's
important. All the Teller knows about the object is the interface it
implements -- the implementation (the class file) comes across the
wire along with the object itself, so the Teller has no way of
determining how the object will actually process the messages sent to
it. This abstraction is a good thing because it lets us change the way
the Withdrawal_slip object works without having to change the Teller
definition.)
The Teller object tells the Withdrawal_slip object to display a user
interface. (The object complies by rendering a UI on the ATM screen
using AWT.)
Bill fills in the withdrawal slip.
The Teller object notices that the initialize-yourself operation is
complete (perhaps by monitoring the OK key), and passes the filled-out
Withdrawal_slip object to the server-side Bank_officer object (again
by value, using RMI) as an argument to the message: "Am I authorized
to dispense this much money?"
The server-side Bank_officer object comes back with "yes" or "no."
If the answer is yes, the ATM dispenses the money. (For the sake of
simplicity, I won't go into how that happens.)
===========
I don't see in here that the various objects don't pass information
back & forth. when 'The Teller object asks the server-side
Bank_records object, "Is the person with this card and this PIN
legit?"' there is DATA being passed. the Teller object sends the card
number and PIN to the server-side Bank_records object. then the
server-side Bank_records object responds with a yes/no. not data, but
info nonetheless.
at every step in the process there is something being passed and
something being returned.
the author of the article goes on to say:
============
The main thing to notice in this second protocol is that all knowledge
of how a balance or PIN is stored, how the server decides whether or
not it's okay to dispense money, and so forth, is hidden inside the
various objects. This is possible because the server is now an object
that implements the "authorization" capability. Rather than requesting
the data that we need to authorize a transaction, the system asks the
(server-side) Bank_officer object (which has the data) to do the work
for us. No data (account balances or PINs) is being shipped to the
ATM, so there's no need to change the ATM when the server code
changes. Also note that the Teller object isn't even aware of how the
money is specified. That is, the requested withdrawal amount is
encapsulated entirely within the Withdrawal_slip object. Consequently,
a server-side change in the way money is represented is entirely
transparent to the client-side Teller.
=============
this seems, to me, to go along with the method of using a general
slider object that knows nothing about movieTime or the like. it just
says to the QTObject "the user has moved me to 35% of the total amount
available, do with it what you will."
the question now is how to deal with updating the slider's position as
the movie progresses. is the solution sending a request to the
QTObject for the current % of completion, or is the use of a callback
warrented?
Al Hospers
CamberSoft, Inc.
al<at>cambersoft<dot>com
http://www.cambersoft.com
Shockwave and Director development, Lingo programming, CGI scripting.
A famous linguist once said:
"There is no language wherein a double
positive can form a negative."
YEAH, RIGHT
[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!]
