Re: [Meta,OT] OOP and Forks
Re: [Meta,OT] OOP and Forks
- Subject: Re: [Meta,OT] OOP and Forks
- From: has <email@hidden>
- Date: Sat, 2 Feb 2002 02:44:52 +0000
Jeff Baumann wrote:
>
I'm a bit puzzled philosophically. Maybe someone can shed some light.
>
>
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.
I'm not sure that I see the comparison between data/resource forks and
language nouns/verbs myself. Resource forks are [by my understanding]
simply structured storage, intended mainly to hold the fancy widgets
(windows, icons, etc) used in the MacOS. Data forks are unstructured
storage, mostly holding user data. (BTW, PPC code is held in the data fork,
while 68K code appears in the resource fork.)
Procedural/structural programming is based on separate verbs and nouns.
This is where most ASers are at.
>
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.
You're right that objects in OO combine both the data and the handlers
(methods) required to manipulate that data. It's not quite true that you
don't have to know anything about an object to use it; rather, you don't
have to know anything about its _internal_ design. You do need to know
about its "public interface" - that is, the handlers that the object's
designer deliberately provides for others to use.
Personally, I don't really like using the "noun"/"verb" terminology. I much
prefer talking about "objects" and "messages"; you tell an object to do
something by sending it a message. It's a bit like saying "Mr Filing Clerk,
please file this document for me", or "Please prepare lunch, Mrs Cook".
I think a simple way of looking at OO is that you always know exactly where
to find the handlers required to manipulate a certain type of data; i.e.
simpler to use. It's impossible to use an inappropriate handler by
accident, since the object only contains the proper handlers to use with
that data; i.e. behaves as a 'gatekeeper'. Finally, you only have to think
about one thing [the object] instead of two [data and separate handlers];
i.e. easier to conceptualise (particularly complex designs).
OO is designed to help coders manage complexity better than could be done
using earlier techniques (e.g. structured programming). For simple code, it
may not make a difference, but as your code grows bigger and more
complicated this becomes more important.
>
These seem like two very different ways to structure things.
Polar opposites. <g>
>
For me, I very much like the idea that nouns and verbs (data and code) are
>
separate. That way,
>
multiple different handlers can each work with the same data.
In OO, you can have as many handlers as you like in a single object. In
addition, inheritance mechanisms provide a way to share handlers (and data)
between different objects. So this is not an issue. You do, however, have
I think which system feels most comfortable may depend partly on which one
you're used to using: if you're using procedural then you tend to think one
way; if you're using OO then you think another. It's also a bit of a jump
going from one way of thinking to the other. Still, that jump can be worth
making if you're struggling to produce complex designs using purely
procedural techniques. If not, no sweat.:)
>
Am I missing something? Is this a meaningful paradox/dichotomy that I am
>
seeing? Can both philosophies coexist in a Mac/Unix world?
In the end, they're all just tools; perhaps the best thing to do is to have
some awareness of the options available and what their main strengths and
weaknesses are. Then you'll be in a better placed to make an informed
decision about which one will be best for a particular job.
Hope that helps...
has