Jonah Thomas wrote:
> I've consistently avoided OO. I've tried to avoid problems that are
> complicated enough for OO to be valuable.
>
> But various recent clf posts have given me the idea that these days,
> avoiding OO is like avoiding structured programming. You can maintain
> software adequately without formal structuring, but there's no point
> trying to get anybody to believe you.
....
OO is a tool. Like many other tools, it's designed for a particular
class of problems. It is not a panacea for all programming, but is
extremely valuable for the right kinds of problems.
Chuck Moore independently developed an OO system for image processing in
the mid-70's. Called "imageFORTH" it was used in a number of
installations with different image processing equipment and different
applications. In this scheme, the basic object was an "image". It had
properties (dimensions, resolution, etc.), and methods (read-line,
write-line). It had inheritance, polymorphism, and all the other
features that later characterized OOP. But the key concept was the
identification of an *image* as an entity with these properties, so that
you could define images that resided on disk, screen, or printer, for
example, and apply common commands. For example, to display an image
named Image1 which resided on disk on the screen, you could say,
DISK IMAGE1 SOURCE SCREEN DEST PASS
or route the displayed image to the printer by saying,
SCREEN SOURCE PRINTER DEST PASS
(there was a lot more to it than that, this is just a superficial
description)
Putting together applications on top of this structure became extremely
simple and readable.
We next encountered objects when working on an industrial
process-control application in the mid-80's. By this time, there was a
lot of literature on OOP, and we were able to formalize our objects more
conventionally. This application area had a lot of devices that fell
into cl*****: conveyors, lifts, dumpers, gates, etc. Each class had
characteristic properties (control points, states, etc.) and methods
(OPEN, CLOSE, START, STOP, etc.). At the same time, we extended OOP
features into our data base toolset, objectifying file cl*****, methods,
etc.
GUI programming is a natural op****tunity for the kinds of
simplifications that result from an appropriate use of OOP strategies,
since there are many cl***** of objects (windows, dialog boxes, radio
buttons, etc.) with common requirements, so we added SWOOP to SwiftForth.
However, there are also a very great many situations in which OOP is not
appropriate, such as most embedded control programs that are entirely
procedural. If you *have* an app with identifiable cl***** of objects,
OOP techniques can provide enormous simplification at the higher levels
of the application. If you don't, it won't do anything for you. So,
it's not appropriate to say "OOP has failed" or even "OOP is great". It
*can* be great if the situation is appropriate.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
|
