From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 24 Apr 93 02:59:48 GMT From: mole-end!mat@uunet.uu.net Subject: Re: Documenting Individual Objects Message-ID: <1993Apr24.025948.25203@mole-end.matawan.nj.us> List-Id: In article , henley@eng.auburn .edu (James Paul Henley) writes: > In article thinman@netcom.com (Technically Swe et) writes: > >johnson@cs.uiuc.edu (Ralph Johnson) writes: > >>The reason for this is that (in my opinion) documenting a single > >>class is easy, and is similar to traditional function-oriented > >>documentation, but documenting object-interactions is much harder. ... > >Perhaps you should be able to specify when and how objects interact? > >Then you wouldn't need to document... the code would serve. ... > In a dynamic chemical process simulation using OO methods, I doubt if there > are many non-chemical engineers who could describe the object interations. > The object interactions is the heart of the simulation, but that requires > domain specific knowledge to understand. ... > So, it requires a domain expert to document how the objects work together. > That is the point that gets lost all too often, but is the key factor in > making OO successful. Which is why most of the interesting OO examples are taken from computing problems (including human-machine interface). -- (This man's opinions are his own.) From mole-end Mark Terribile mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ