Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!cimshop!davidm
From: davidm@cimshop.UUCP (David Masterson)
Newsgroups: comp.lang.c++
Subject: Re: Objectifying incoming messages?
Message-ID: <455@cimshop.UUCP>
Date: 4 Aug 89 18:20:36 GMT
References: <444@cimshop.UUCP> <452@cimshop.UUCP> <533@ajpo.sei.cmu.edu>
Organization: Consilium Mt. View CA
Lines: 56
In-reply-to: eberard@ajpo.sei.cmu.edu's message of 3 Aug 89 15:40:39 GMT

In message <533@ajpo.sei.cmu.edu>, eberard@ajpo.sei.cmu.edu writes:
>There are quite a number of other issues and solutions I would like to
>discuss, but I have already taken enough space.
>
Discuss more... Discuss more...  I agree with you that there are quite a
number of interesting issues here that need to be discussed in order for the
object-oriented paradigm that C++ uses to move out of the single process type
of development into a more multi-tasking environment (yes, you can write
multiple cooperating tasks in C++, but does C++ effectively define how they
will interface?).

>[stuff deleted]				 There
>are two types of object coupling: white-box object coupling and
>black-box object coupling.
>
Your definitions and examples here threw me some.  I think I understand what
you're talking about, but never before put names to it, so I'm having trouble
matching up what you're saying with what I think I know.  I'm interested in
how coupling might go too far and where the cross-over point from black to
white is (is it really that black and white?).

>       Because the "display" operation is required to change the
>state of an object which is not an instance of the counter class
>(i.e., it must change the state of some "output object") we say that
>the counter object is white-box coupled with the "output object."
>
I don't understand "output object" or "display".  Isn't it more appropriately
called asking the "counter" object for its current value?  Is that black or
white coupling (one object requests information from another)?

>[By the way, there are specific techniques for removing undesirable
>object coupling. There are also specific guidelines for both avoiding
>unnecessary object coupling, and in the construction of reusable
>systems of objects.]
>
Where?  I think I want to look this up.

>Objects encapsulate:
>
>	- knowledge of state information
>	- operations (and their corresponding methods)
>	- other objects, i.e., there can be:
>		- homogeneous composite objects
>		- heterogeneous composite objects
>	- exceptions
>	- constants
>	- concepts
>
Agreed about composite objects (a point I've been trying to make around here).
Could you define "exceptions, constants, and concepts" more?  Particularly as
to transferring this information from process to process?  A similar question:
should processes be thought of as objects and what implications does that
have?

David Masterson					(415) 691-6311
uunet!cimshop!davidm		or		DMasterson@cup.portal.com