Re: Script Libraries
Re: Script Libraries
- Subject: Re: Script Libraries
- From: has <email@hidden>
- Date: Thu, 4 Nov 2004 18:07:08 +0000
Simon Forster wrote:
Grazing through the list I read one of HAS's posts concerning the
loading of libraries and making sure that they don't have cross
dependencies.
Dependencies are inevitable in any code. The problem isn't in having
dependencies, it's in having _too many_ of them. (FAR too many in the
OP's case, since he links everything to everything else; the very
antithesis to modular design.) The trick to programming isn't writing
code (any fool can do that), it's keeping complexity under control.
Good programmers design for simplicity; the bigger the program, the
more important this becomes.
Look up the terms 'cohesion' and 'coupling' as they relate to
programming, either in a textbook or online. Good code has high
cohesion - each component (function/class/module) has a single,
well-defined purpose - and low coupling - each component has few
connections to other components. (There's absolutely no shortage of
literature on this stuff, so you needn't rely on my hamfisted
attempts at explaining it.;)
I have a script which uses 4 different libraries - libFinder,
libString, libMisc and another which I've forgotten. So we have 3
libraries ;-)
I'd immediately be wary of any module named 'libMisc' - the name
alone strongly suggests poor cohesion.
These libraries are loaded by the main script and assigned to globals.
Don't want to get sidetracked into implementation issues here, so
please refer to the following posts to the Studio list for an
explanation of why you should never use globals in modules:
http://lists.apple.com/archives/applescript-studio/2004//Nov/msg00016.html
http://lists.apple.com/archives/applescript-studio/2004//Nov/msg00018.html
Some of the handlers in the libraries use functions defined in other
libraries.
Libraries having dependencies on other libraries is not in itself a
bad thing. There is not a problem, for example, in library A using
library B and your main script using both A and B. You can write and
test library A in isolation first. Once you're happy with that, write
and test library B, and when that's done finally write and test the
main script. If, however, A is dependent on B *and* B on A, you can't
test anything until A and B are both done. You've gained nothing over
writing both as a single script.
Here's an exercise: assuming the worst case where every component is
coupled to every other component, how many interconnections will you,
the developer, have to keep track of if your system has two
components? How about 3? 5? 25? You'll notice that the number of
connections increases as the square of the number of components. Each
of those dependencies means additional complexity: more information
to remember, one more thing to potentially go wrong.
This isn't such a big deal when your programs are small and simple,
but becomes increasingly important as they grow ever larger and more
ambitious: while some complexity can never be reduced and is
therefore inevitable, non-essential complexity is something you
ignore at your peril. As a rough rule of thumb: if something seems
too complex, it usually is. Redesign it so it isn't. The human mind
can hold 7 +/- 2 pieces of information at any one time. If you have
to track a couple dozen dependencies any time you modify a piece of
code, you're going to need a much bigger brain. To quote Alan Perlis:
"Fools ignore complexity. Pragmatists suffer it. Some can avoid it.
Geniuses remove it." :)
HTH
has
p.s. If you check out the libraries on AppleMods, the LoaderTools
library includes some nice tools for viewing library dependencies.
The dependency graphs for some of the more powerful libraries (e.g.
HTMLTemplate) can be quite deep, but even then they remain very
narrow - you'll rarely find a individual component with more than a
couple direct connections to other components - and I don't think
there's a single circular dependency amongst the whole lot (though
Loader is perfectly capable of handling these) - their trees are
straight from top to bottom.
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden