Re: OO Theory misconceptions (was Re: can I make a list of
Re: OO Theory misconceptions (was Re: can I make a list of
- Subject: Re: OO Theory misconceptions (was Re: can I make a list of
- From: "Jason W. Bruce" <email@hidden>
- Date: Fri, 01 Feb 2002 17:56:01 +0000
Timothy Bates <email@hidden> wrote:
>
That is a very cool example, but I think what is missing is the ability to
>
have an initialisation handler called on load script
>
>
Set bill to load script file.lib
>
>
bill's birthday()
>
--> "I was born on 1/2/02"
>
>
Where on load script, a handler called initialise() is called, which does
>
some setup and creation-time stuff (in this case, setting a birthday
>
property).
I think this feature is present in the language. If you load a script as a
parent to the current script, the loaded script's implicit run handler will
execute:
property parent: load script file.lib
So, if the loaded script has its own initialization routines invoked by its
implicit run handler, I think this method will call them automatically.
Constructor functions, inheritance, and instances are great, but to me the
real value of OO in AppleScript is that it's simply a way of breaking down a
complex script into manageable parts.
Many people start scripting by just stringing together a long series of
commands. When these commands exceed a certain length, this approach
becomes difficult and unmanageable. The next level of organization is to
break these series of commands into discrete handlers which your script
calls one after another. When the string of handlers become too long, this
approach can also become difficult and unmanageable. So the next level of
organization is to break these handlers into groups and put them into script
objects.
For example, if you have a script which collects data from a FileMaker Pro
database, creates a Quark document with that information, sends an email
notification, and then checks as completed a task in the Palm Desktop, you
can create in your script a script object named filemaker which has all your
handlers targeted to FileMaker Pro, a script object named Quark which has
all your handlers targeted towards Quark Xpress, a script object named OE
which has all your handlers targeted towards Outlook Express, and a script
object named Palm which has all your handlers targeted towards the Palm
Desktop. Instead of calling a series of handlers, you now call filemaker,
Quark, OE, and Palm.
When you want to add a handler or feature sixth months or a year later,
you've created a clean organizational structure so you know right were to go
to add the feature -- and adding it doesn't affect any of the other portions
of the script outside of the script object. Inheritance and instances and
constructor functions are great. But in the end, it's the modularity of OO
that is in my opinion the real advantage.
Jason Bruce