Applying object-oriented concepts to documentation

Subject: Applying object-oriented concepts to documentation
From: Steve Owens <uso01 -at- EAGLE -dot- UNIDATA -dot- COM>
Date: Tue, 12 Apr 1994 10:25:02 +0700

> Out of curiosity, is anyone aware of the notion of applying object-oriented
> concepts to creating online documentation? I recently read a paper on this
> ("Applying Object-oriented concepts to Documentation," by Sky Matthews and
> Carl Grove, in the SIGDOC '92 proceedings), and was wondering if anyone has
> applied these concepts in their own projects.

Hm... I'd be interested in hearing a bit more about this. I
can take some guesses at how to apply OO to documentation (this is
where SGML comes in, actually :-) but I'd like to hear what approaches
others are using.

I'd assume one primary concept is single sourcing the
different components so your DTP tool pulls them together into a
single document in the combination necessary. Thus if you change, for
example, your standard disclaimer, you don't have to edit every single
document that includes it.

I'm a little curious as to how to apply inheritance - perhaps
inheriting format templates? This could be interesting... For those
unfamiliar with OOP, here's a brief description. Some of the
essential concepts of object-oriented programming are:

data hiding

These allow the design of the program to be more abstract,
less concerned with the low-level details (until it's time to be
concerned with the low-level details).

I'm winging this, since I'm familiar with the concepts but not
with most of the conventional OOP languages. Again, anybody with real
exposure to the concepts is invited to pull my foot out of my mouth.

An "object" in object oriented programming is a construct of
data and code. Rather than directly munging the data to get it to
where you want, you talk to the code that is part of the object, which
then munges the data, figures out whatever it is you asked for, then
relays that information back to you. Anything that has to do with the
concept that object construct embodies is built into that object
construct. Code in the rest of the program simply manipulates the
object. This is called "encapsulation."

The object construct can also have an underlying structure of
code and data - things *it* uses to do its job, but which aren't
accessable to the outside program. Because they aren't accessible,
you can build a program that uses a standard object, then later go
through and redesign that object for greater efficiency. However,
because you don't change the interface to the object, you don't have
to change the rest of your program. The internal stuff has to be
hidden to keep people from trying to use it anyway (something
programmers have a tendency to do :-). This is called "data hiding."

Now, you don't want to build every object from scratch - odds
are, you're going to use any given object a number of times, in
different places in your code. Sometimes you'll need several
instances of an object in the same section of code. So you design a
"class" of objects, and then you instantiate (create an instance of)
that class when you need that kind of object.

Sometimes you'll need one version that is just slightly
different from another, just a little bit more complicated, with some
additional functions. You could make a copy of the first class, then
add the data and code for your needs. This has a few problems,
though. First, you're duplicating code, so you're taking up more
space. Second, if you decide at a later date to go back and redesign
some of the code in the object (something that is very probable in
programming) you now have to add the changes to two locations - or

So instead of copying the code, OO lets you set up one class
to be the "child" of another class (the "parent" of the first class).
The child can in turn be a parent and have children of its own. The
effect of the parent/child relationship is that the child "inherits"
the attributes of the parent, and can have additional attributes, to
be more complicated. This is called "inheritance".

To put this into a physical analogy, consider a cigarette
lighter. You have fuel, flint, steel, all of which have to be
manipulated in the right way at the right time.

In the old days, you had all of these elements individually
(usually stored in a little tinder box), and when you needed to light
a fire you sat down, layed them out, set up the fuel so you didn't
have to hold it (which is why they used tinder back then), and
manipulated the flint and steel. This is what non-OO programming is

These days, all of these elements are "encapsulated" into a
cigarette lighter. You know there's flint, and there's fuel, but you
really don't care - you just flick the switch and flame comes out.
Instead of manipulating the internals of the object - the cigarette
lighter - you're just using the interface - the switch. You don't
have to know how the internals are arranged, or even how they work,
really. You could pick up a different version and use it all the
same, because the interface is the same.

Inheritance is a little trickier to demonstrate in this
analogy - the closest I can come is all the different colors, shapes,
and sizes of butane lighters out there, all built around the same set
of components organized the same way.

Steven J. Owens
uso01 -at- unidata -dot- com

Previous by Author: Job hunting
Next by Author: Synonym for Remote?
Previous by Thread: Applying object-oriented concepts to documentation
Next by Thread: What are we doing to our re

What this post helpful? Share it with friends and colleagues:

Sponsored Ads