TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Use of Object Oriented Programming Terms in Documentation
Subject:Use of Object Oriented Programming Terms in Documentation From:Harold Henke <hessian -at- VNET -dot- IBM -dot- COM> Date:Mon, 10 Oct 1994 15:20:08 MDT
Should a rose be called a rose or should a rose be called an object
with attributes such as color, size, smell and so forth. Perhaps
more simply stated, when you are documenting an object oriented programming
(OOP) product, should you use OOP terms to describe functions?
For instance, we have an object called a physical printer that has
many attributes, such as paper trays and so forth. Do you all call that
printer a "printer object" and the paper trays a "printer object attribute"?
Since a physical printer is represented by a collection of information that
we call an object, it makes sense to use the OOP terms but how many
people, who want to submit a job to a printer, or who want to make sure the
printer is not jammed, care about OOP terms? As a writer, use of OOP terms
makes it easier to explain the relationships between the physical printer,
the logical printer, and other collections of information. But some folk
seem to think OOP terms are too conceptual for most readers.
If you are writing about a product that uses OOP technology, could you post
a note? And can you answer this question: "Do you use the word object in
your documentation?"
