[Tutor] OO scripting in python...

[Michael P. Reilly]

GADGIL PRASAD     /INFRA/INFOTECH wrote
> I am coming from moderate C, basic C++ knowledge, and some perl exp.
> 
> For OO scripting, the basic concepts I learned during c++ seems
> rather unconnected when I read py-tutorial chapter 9 (classes). 
> It seems individual languages like perl, python implement various
> basic concepts of OO in such different ways, with such varying grammer,
> especially with perl, I was totally confused with 
> 'perltoot' (perl- tom christian's O. O. tutorial')
> It seemd c++ is rather straight forward than that.
> 
> I am not that confused after chapter 9, but I don't have OO coding exp., 
> and things are not very clear either.
> 
> Do I need to buy a book to be able to do OO programming
> in python ?
> 
> Can someone pl. explain oo coding in a 10,000 feet overview ?

Well.. first is that there are a lot of different philosophies for
object-oriented programming.  But how I tend to think about it is
that you don't want to think about the programming, concentrate on the
object-oriented design.

"Object-oriented" basically means that instead of procedures and data
structures, your program wants to think of objects and behaviors of
the objects.

One classic example program is a bank.  You have a teller and some
customers, a line to wait in, transactions for each.  In "normal"
(procedural) programming, you would have a structure for the teller,
one for the line (queue), and possibly structures for the transactions
since that data is more important than the customer information.

Something like:
  assign values to teller structure
  define queue for transactions
  check_for_new_transactions(queue)
  until queue is empty:
    next = get_next_transaction(, queue)
    process_transaction(teller, next)
    check_for_new_transactions(queue)
Here, the routines are typically geared to the precise data structure
being passed.

With object-oriented programmer, you would have a teller object, which
would have a queue (with a "interact_with_next_customer" method?), and
customer objects.  The behavior between the tellers and customers is more
important: customer must fill out deposit slip, teller must check account
information (right bank, valid account), customer must pass over money,
teller must return a receipt.

How about:
  create new teller object
  create new queue object, associated with teller object
  queue.check_for_new_users()
  until queue is empty:
    user = queue.get_next_user()
    teller.process_transaction(user)
    queue.check_for_new_users()

Now this doesn't seem all that different.  But let's replace the teller
with an ATM.  The transactions might be the same, but the routines called
would be very different in procedural programming (since most are are
typed languages).  However in object-oriented programming, we can make
an ATM object that behaves just like the teller object and the rest of
the program wouldn't have to change much.  Or if the user was now an
online user and the queue was from a webpage, then those could be more
easily changed as well.

What is commonly thrown about is "code reuse".  As you can see, if
designed correctly, things like the queue, user, teller can be reused
more easily than the functions in the first example (but all can be
reused if all designed correctly).

  -Arcege

PS: IMO, Perl makes things very confusing in general, and how they added
"objects" in Perl5 was especially so.  Congratulations on actually making
it through that document.

-- 
+----------------------------------+-----------------------------------+
| Michael P. Reilly                | arcege@speakeasy.net              |