> I have been writing Object-Oriented ProgramS (-: oops! :-) for a few
> days now. I am muddling along quite nicely, but how should I aim to
> program?
> a) Write conventional programs via methods that operate on objects as data?
> b) Write objects that have methods bound to slots via wrappers so that
> accessing data performs programmed actions?
> c) Some marvelous, better way that you know of and are just about to tell me?
> I sort of like (b) from an AI point of view ... then I imagine this
> great big can of worms all wriggling and biting each other! Then I think
> of Aaron's views on artificial minds ...
> Seriously, though, what should I be trying to do?
> James Anderson
There are several good and not-so-good introductions to OOD (OO design)
which are supposed to tell you how to do OOP properly. Lots of people
making lots of money telling us how to do it! But actually one of the
best books I've seen is by our friends at HP (Chris Dollins and others)
which describes the HP approach. Better still, it says what it weas in
a lot of the other approaches. Recommended. It is called "Object
Oriented development: the fusion method", Derek Coleman et al.,
Prentice-Hall.
Actually, none of these books *really* tell you how to do OOP properly.
The gist is that you should be able to "naturally" identify the objects
in your application, eg if you were writing a timetabling program, then
I guess natural classes would be "students", "teachers", "subjects",
"classrooms" and no doubt you can think of others. Whether or not these
are the right classes for a timetabling program requires experience of
writing time-tabling programs! Like any other way of doing software
development, experience is the best teacher.
So that's how you identify your objects. What about methods? I find that
the distinction between active objects and passive objects can help
(incidentally, this is not quite the same distinction that Grady Booch
makes (Grady Booch is one of the people who makes lots of money telling
everyone else how to do it)). For me, an active object is one that does
things to passive objects, so an active object will use the methods of a
passive object to change the passive object. And the "doing things"
procedures will be methods of the active object. Quite often you will
only have one instance of an active object class. I realise this
description won't help much .... a metaphor might help a bit. This isn't
actually how I would write an editor using OOP, but you could think of a
VED object which is an editor, and is an active object, and ved buffers
could be passive objects. The procedures like ved_j would be methods of
the vedbuffer which could be called by the editor object. Different
kinds of vedbuffer would have different justify procedures (eg pop11
vedbuffers, prolog vedbuffers, text vedbuffers etc.)
Cheers,
Jonathan
|