From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: *
X-Spam-Status: No, score=1.8 required=5.0 tests=BAYES_40,FROM_STARTS_WITH_NUMS,
	INVALID_DATE autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!NAVPGS.BITNET!4526P
From: 4526P@NAVPGS.BITNET ("LT Scott A. Norton, USN")
Newsgroups: comp.lang.ada
Subject: Re: Object oriented programming (OOP)
Message-ID: <8612180505.AA27665@ucbvax.Berkeley.EDU>
Date: Wed, 17-Dec-86 13:40:13 EST
Article-I.D.: ucbvax.8612180505.AA27665
Posted: Wed Dec 17 13:40:13 1986
Date-Received: Thu, 18-Dec-86 07:32:28 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
List-Id: <comp.lang.ada>


Thank you, Larry, for the clear explaination of OOP.  I would like to add
a few comments to address the design phase that preceeds OOP. These comments
are based on the work I've read of Dr. David Parnas.
   To enable OOP to "tend to produce programs that need little change or can
be easily changed," the objects that are defined should encapsulate those
aspects of the project likely to change.  Parnas calls these details the
secrets of the module that defines the objects.  Then, when a requirement
changes, the program change is isolated to that module.
   For object-oriented programming to be totally effective, the design
of the system must explicitly consider what design decisions are likely
to change, and use that as the criterion to define objects.  As Parnas found
in his study of the A-7 aircraft's tactical program, this design requires
significant amounts of research, and should not be a decision that the
programmer makes sitting at a terminal.  The designers must invest extra time
before coding starts.

LT Scott A. Norton, USN
Naval Postgraduate School
Monterey, CA 93943-5018
<4526P@NAVPGS.BITNET>