Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!linus!snorkelwacker.mit.edu!hsdndev!cmcl2!lanl!Eric
From: Eric Wasserman
Newsgroups: comp.sys.mac.programmer
Subject: Re: OOP--What do you think?
Message-ID: <20936@lanl.gov>
Date: 11 Apr 91 16:39:59 GMT
References: <1991Apr10.210516.25812@rice.edu>
Sender: news@lanl.gov
Reply-To: egw.weakm@p3.lanl.gov
Organization: LANL
Lines: 57

In article <1991Apr10.210516.25812@rice.edu> koops@elf.rice.edu (Ryan Richard
Koopmans) writes:
>I recently purchased THINK C 4.0.  When I looked at their
>object oriented implementation of the Mac interface, I was
>more than a little bit confused.  I've written lots of Mac
>applications before, and I'm comfortable with the traditional
>procedural kind of Mac programming.
>
>What I want to know is, is OOP the wave of the future in
>programming or just a passing fad?  Is it worth learning
>a new way of programming just to use the TCL?
[...]

I've been using the Think Class Libraries for several months now and I think
that they are a great help in getting the user interface side of applications
done quickly and well. If you like, you can leave it at that and do all the
real work in essentially a procedural fashion (i.e. don't use objects to do
whatever it is that goes on behind your user interface).

I don't agree with the complaint that this is too abstract and takes you too
far from the machine.  Passing a message is really just calling a subroutine. 
The Think Class Libraries do put a layer between you and the machine but let's
face it, the Mac's ROMs are a much bigger black box than the Class Libraries
especially since you don't have the source for the former.

The Think implementation of OOP is really not all that complicated. I recommend
writing a dumb little program to convince yourself that you understand
polymorphism and so on.
 
On the other hand the Class Libraries have a pretty steep learning curve though
its not anywhere near as bad as learning the Toolbox from scratch. The best
thing to do is read the overview a couple of times (esp. the chain of command
and visual hierarchy parts), browse the descriptions of the important classes
(CApplication, CDirector, CDocument, CWindow, CPane, and the CPane subclasses
you are interested in), make a copy of the starter project and start modifying
it a little  bit at a time.  Don't get too bogged down trying to figure out the
details (eg. the event loop in the CSwitchboard or the message dispatching--use
the source debugger someday to see how this all works though).

Everyone I know who's started using OOP and the TCL has first told me that its
stupid and not worth the trouble.  Then they've come back and said they've
"seen the light" and would never go back.  I think its well worth trying out
for yourself. I for one use the TCL extensively and furthermore have made OOP
an integral part of my non-interface programming as well. For me, OOP is
largely a new way of looking at some problems. Not every problem is amenable to
such a viewpoint but for those problems you can restrict the OOP component to
the user interface.

It is, of course, possible to go too far with OOP by trying to make everything
into an object. For example, I've seen a commercial object- oriented plotting
package which makes each data point into an object. One needs to avoid forcing
the paradigm on every aspect of every problem.

Give it a try. Good luck.

Eric
egw.weakm@p3.lanl.gov