Re: [Meta,OT] OOP and Forks
Re: [Meta,OT] OOP and Forks
- Subject: Re: [Meta,OT] OOP and Forks
- From: email@hidden
- Date: Fri, 1 Feb 2002 21:42:33 -0500
On Fri, 1 Feb 2002 01:57:59 EST, email@hidden
>
When the Mac was created, Apple decided that files of all types should have
>
resource forks and data (including programming code) forks. This basically
>
kept the nouns and verbs separated, and allowed fascinating things like
>
ResEdit to exist. IMHO, it was brilliant.
>
Putting the code in the data fork is a recent innovation and a kludge, to create
fat applications. The PowerPC code needed to go somewhere, and the data fork
was available. On 68K applications, the resource fork contains code resources
as well as "data" resources.
The real differences between forks is that the resource fork has a defined
structure, which the developer can simply access using system calls. So its
convenient. The data fork is a plain stream of bytes, which the developer can
use as he wishes. Its flexible, but you get no help from the OS.
>
OOP, as I grok it, involves "objects" which internally contain their own
>
nouns and verbs and you don't need to know anything about them, just enter
>
thru the front door and pay your money please.
>
>
These seem like two very different ways to structure things.
They are. They are driven by two different engineering considerations.
OOP is about controlling complexity. It allows the developer to group together
the pieces of the program that are interdependent on each other, and separate
the pieces that don't work together. The idea is to minimize coupling and
maximize cohesion. Coupling is the need, when you change some code *here*, to
then change some code *there* to match, while cohesion is the benefit that
results when two things, that inherently have to change together, are located
near each other.
What makes object-oriented design different from the structured design approach
that preceeded it is that OO groups together both the code and the data.
Structured design, with functions and libraries, only grouped together code that
did the same things, and so missed the fact that the data structure details
imact the code strongly.
Resource forks are driven by the need to manage complexity resulting from the
shear quantity of stuff, rather than the complexity from interconnection and
coupling. There's just all those strings, icons, pictures, windows, and other
resources. They change throughout the development process, they need to change
for internationalization, and you really can't get them just right until you
have all the application working and have exposed it to users in prototype
testing in that room with the one-way mirror.
Resources are also good for system stuff that the developers can assume will be
there and are in a format defined by the OS developers. Coupling to documented
OS stuff is less of a problem because its is less likely to change. (This is
why developing against a beta OS is soooooo painful--you are strongly coupled to
something that is changing.)
And once you have the resource structure available through OS calls, the
resource fork is a handy place to store your own data. Now, if the OS provides
a different way of storing data (like the Unix environment, or the OS X XML
plist, or the Windows registry) you might put the program's data there. But
that's not a matter of elegance of design at the high levels, but simply a
matter of convenience at the low levels.
>
For me, I very much like the idea that nouns and verbs (data and code) are
>
separate. The only nouns I let my objects have are throw-away temp variables
>
and data structures built dynamically from a common source. That way,
>
multiple different handlers can each work with the same data.
It sounds like the objects in your designs are the union of the "multiple
different handlers" and the "same data" they work with together.
If you can use an existing data structure, great. Then, you don't have coupling
between your code and the data, because the data doesn't change. But most big,
complex programs define their own data abstractions, and need to have their code
and data grouped together into an object, which is an abstraction of their
behavior together.
>
Am I missing something? Is this a meaningful paradox/dichotomy that I am
>
seeing? Can both philosophies coexist in a Mac/Unix world?
They are both useful tools. Use the standardized capabilities of the language,
platform, and environment when you can. Use design methods, like object
oriented design, to manage the complexity that occurs when you can't use the
standard capabilities.
--
Scott Norton Phone: +1-703-299-1656
DTI Associates, Inc. Fax: +1-703-706-0476
2920 South Glebe Road Internet: email@hidden
Arlington, VA 22206-2768 or email@hidden