Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Anthony Menio <menio@pegasus.montclair.edu>]

On Mon, 11 Nov 1996, Daniel Drasin wrote

> You are both right (and wrong).  The question is, what is the point of
> the distinction.  P.G.  Just 'cause you can't "see" the objects doesn't
> mean that they're not there.  E.g. A psychiatry textbook will describe
> behavior of "humans," "men," and "women."  These are types but clearly
> in actual application, these "laws of psychiatry" apply to the actual
> individual people involved.  
> 
> Smalltalk, C++, and java use what's called "class-based programming"
> which
> means that the behavior of individual objects is described by its 
> type or class.  Therefor classes will be manipulated in order to affect
> the behavior of objects.  Which leads back to by origional question:
> What is the point of the distinction?  What is the point of saying
> that an OO program is the interaction of objects (and not classes)?
> If the point is to direct the student to understand the runtime behavior
> that needs to be focused on, then objects are what the program consists
> of (ognoring the reflective meta abilities...).  However, if the aim
> is to understand what must be created at compile time in order to
> create a program, then "classes" are the elements are the program.
> 
> Dan


The classes are simply blue prints of the the objects which
can be created, and thus describe the attributes and behavior
of objects. The runtime system consists of objects and these
are what must be specified and the interactions between them
at implementation time. Your source code consists of instances
of these classes and the messages you designate to have
happen and the states and messages these result in across the
system. The messages you designate might simply create the
system (constructors) and determine interobject relations and
than wait for user messages.The system
you build is thus described by the objects created and the 
methods you specify to be called
and the states these create and manipulate a runtime.
Classes are simply blueprints and thus describe the
domain of states and possible behaviors an instance can
assume. A software system consists of assumed behavoirs
and determined behavoirs in response to runtime
user messages and thus of objects.
In terms of source code your system is really 
object creations and method invocations that occur at runtime
implied by code like the following:

Application my_App();

myapp.setDbase("Oracle");

FileSever netsever10(CURRENT_IP);

requestObject *action= application.idle();

if (interupt)
{
netserver.request(requestObject);
myapp.continue(requestObject);
}

further more even this is simply a blue print for
the system as a whole the true system only exists at runtime
however even its implementation description refers to definite
articals to be created ie objects. I think this distinction
maybe subtle but is important.  

Anthony Menio
I.S. Student
menio@pegasus.montclair.edu

	Your power is your ideas, your ideas are products of
	perception, your perception is the product of your
	architecture, architecture is everything - me