Path: utzoo!attcan!uunet!image.soe.clarkson.edu!news
From: cline@cheetah.ece.clarkson.edu (Marshall Cline)
Newsgroups: comp.object
Subject: Re: Display methods, pro or con...
Message-ID: <CLINE.90Aug8122645@cheetah.ece.clarkson.edu>
Date: 8 Aug 90 16:30:05 GMT
References: <1681@dinl.mmc.UUCP> <25966@bellcore.bellcore.com>
Sender: news@sun.soe.clarkson.edu
Reply-To: cline@sun.soe.clarkson.edu (Marshall Cline)
Organization: (I don't speak for the) ECE Dept, Clarkson Univ, Potsdam, NY
Lines: 44
In-reply-to: sjs@roland.ctt.bellcore.com's message of 7 Aug 90 15:16:35 GMT

In article <25966@bellcore.bellcore.com> sjs@roland.ctt.bellcore.com (Stan Switzer) writes:
>Quite simply, the question is this: should objects be concerned with
>their presentation?
...
>We can even generalize this a bit.  Should an object's methods be
>concerned with what it is *for* or simply with what it *is*.  Example:
>personnel records.  We should certainly have methods which realize and
>elaborate on the basic concept of personnel records, but should we
>embed intelligence about company personnel policy in these objects?

I'll extend this to: Objects Should Provide Mechanism Rather Than Policy.
Ex: a Circle should enable various `views', rather than a specific policy
of bitmapped display, textual "I am a Circle", etc.  Similar remarks go
for a PersonnelRecord.

It seems to me that this `mechanism-not-policy' issue is the essential
reason why OOD scales better than top-down-structured-design (TDSD).
TDSD percolates policy down from the top.  When (not `if') a requirement
spec changes, huge branches of the TDSD `tree' may need to be lopped off
and modified.  Contrasting, OOD allows mechanism to percolate `up' the
tree (a String provides catenation, copy, printing, etc, but it doesn't
dictate which order things happen).

Since changes in requirement specs are inevitable, only the top `layers'
(the `pure policy' sections) need to change in OOD, since they simply call
on different mechanisms (or different orderings of the same mechanism) in
the lower level objects.

This is also why bottom-up implementation is so horrible in TDSD where
it's not *as* bad in OOD.

Stan is right on target.  Objects must provide maximal mechanism, with
system-wide policy decisions being delayed as long as possible.

Marshall Cline
--
==============================================================================
Marshall Cline / Asst.Prof / ECE Dept / Clarkson Univ / Potsdam, NY 13676
cline@sun.soe.clarkson.edu / Bitnet:BH0W@CLUTX / uunet!clutx.clarkson.edu!bh0w
Voice: 315-268-3868 / Secretary: 315-268-6511 / FAX: 315-268-7600
Career search in progress; ECE faculty; research oriented; will send vita.
PS: If your company is interested in on-site C++/OOD training, drop me a line!
==============================================================================