Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!mit-eddie!bu.edu!rpi!zaphod.mps.ohio-state.edu!usc!apple!portal!cup.portal.com!cdurrett
From: cdurrett@cup.portal.com (chuck m durrett)
Newsgroups: comp.object
Subject: Re: The essence of objects...
Message-ID: <31716@cup.portal.com>
Date: 14 Jul 90 19:15:11 GMT
References: <1280@media01.UUCP> <1964@runxtsa.runx.oz.au> <1288@media01.UUCP>
Organization: The Portal System (TM)
Lines: 37

>Tim Menzies answers
>> yes, yes, yes. oop is a way of normalising procedural knowledge. database
>> designers realised that we had to normalise data decades ago. now, we
>> normalise code as well.
>
>This answer seems to imply that we now normalize code. I think we should
>normalize our code, one way or the other. But it seems that the
>database designers have some formal logic, and at least some understanding
>of what it means to normalize data. I wouldn't know where to start
>to normalize code.
 
>Is there anyone who does? Are there formal techniques like normalizing
>which can be adapted to software design?
>
>I would love to hear about those.
>
>Peter Kriens
>Mediasystemen
 
An object is the fusion of function and state.  When teaching people
about OOP, we use the terms "code" and "data" to help get some of
the ideas across.  Once across, these terms should be dropped.
 
An object is a compound not a mixture.  Eg, I can put sodium and
chlorine on my food but it makes a lot of practical difference
whether they are together as a compound (salt) or a mixture
(burning poison).
 
An object is an instance of a class(ification) or abstraction.
It exhibits behavior.  We shouldn't let our understanding of HOW
it exhibits that behavior interfere with WHAT that behavior is.
 
In traditional programming environments, we manipulate descriptions
about the world (code, data, etc.).  In OO we are working with the
world directly.
 
Chuck Durrett