Class side vs Instance Side?? 
Author Message
 Class side vs Instance Side??

I am new to OO and I think I understand Classes and Instances.  What I don't
understand is what is meant by Class side of the heirarchy and Instance side
of the heirarchy. If instances are instantiated from classes why would not
the heirarchy be the same?  


Sun, 01 Mar 1998 03:00:00 GMT  
 Class side vs Instance Side??

Quote:

> I am new to OO and I think I understand Classes and Instances.  What I
> don't understand is what is meant by Class side of the heirarchy and
> Instance side of the heirarchy. If instances are instantiated from
> classes why would not the heirarchy be the same?  

Think of a class as a factory that knows how to manufacture a specific
type of object as you read the following:


the definition of the "new" method):

Quote:
> ...
> My favorite example is automobiles ( in fact, Ford Taurus').  Let's
> assume you want a Ford Taurus to drive around in.  Well, you have to
> all the Ford Taurus FACTORY to have one built.  This is analogous to  
> sending the new message to the Class.  The main point here is that
> FACTORIES have behavior that is different from the instances they
> create. You could tell your Taurus to accelerate, turn, stop - however
> these messages would be relatively meaningless to the Taurus FACTORY
> (Class).  You could tell the FACTORY to build a new Taurus (new) or ask
> it the default engine size, or the default tire type, etc., again these
> would be relatively meaningless to the individual Taurus.
> ...

Let's say that "FordTaurus" is a subclass of "Automobile".

Class methods are those understood by the factory itself.  Inheritance
along the "class side" of the class hierarchy provides a way of defining
a new factory in terms of an existing one.  E.g. The FordTaurus factory
manufactures FordTaurus's just like the Automobile factory manufactures
Automobile's.  Class methods of FordTaurus are used to supplement or
(only slightly) correct any of that default behavior.  

Instance methods are those understood by the instance, inheritance along
the "instance side" of the class hierarchy provides a way of defining a
new instance in terms of one that would be manufactured by the
superclass.  E.g. a manufacturED FordTaurus operates just like a
manufactured Automobile.  Instance methods of FordTaurus are used to
supplement or (only slightly) correct any of that default behavior.  

I hope this information is either helpful, or makes sense, or both.

----------------------------------------------------------------------

I don't speak for my company                        http://www.amd.com

"In theory, there is no difference between theory and practice, but in
 practice, there is." - unknown



Sun, 01 Mar 1998 03:00:00 GMT  
 Class side vs Instance Side??

Quote:

>I am new to OO and I think I understand Classes and Instances.  What I don't
>understand is what is meant by Class side of the heirarchy and Instance side
>of the heirarchy. If instances are instantiated from classes why would not
>the heirarchy be the same?  

In essence, the hierarchy is the same.  It is simply an 'organizational
helper'. One benefit of this is that one can browse/modify the behavior of
instances (instance side) and, with only the toggle of a button or radio
button, browse/modify the behavior of the class object that is used to create
those instances (class side).

--
-----------------------------------------------------------------
Steve Bannerman                    | Applied Reasoning Systems

(205)403-1141 - BellSouth, B'ham   | (919)781-7997 - Raleigh, NC
-----------------------------------------------------------------
"A heart at peace gives life to the body,
 but ENVY rots the bones" (Proverbs 14:30, emphasis mine)
-----------------------------------------------------------------



Sun, 01 Mar 1998 03:00:00 GMT  
 Class side vs Instance Side??

Quote:

>>I am new to OO and I think I understand Classes and Instances.  What I don't
>>understand is what is meant by Class side of the heirarchy and Instance side
>>of the heirarchy. If instances are instantiated from classes why would not
>>the heirarchy be the same?  

>In essence, the hierarchy is the same.  It is simply an 'organizational
>helper'. One benefit of this is that one can browse/modify the behavior of
>instances (instance side) and, with only the toggle of a button or radio
>button, browse/modify the behavior of the class object that is used to create
>those instances (class side).

That's true, but, just to confuse matters more (I do love confusion), the
split is sometimes called the class hierarchy vs. the metaclass hierarchy
(instead of the instance side vs. the class side).

When you talk about SIDES, it's probably OK to refer to them as instance or
class sides.  However, a moments reflection should convince you that there
really is no such thing as an instance hierarchy.  Since instances get their
behavior from classes, the class hierarchy determines instance behavior.

Then, since classes are objects too (instances of some metaclass), there is
a separate metaclass hierarchy.  The metaclass hierarchy
corresponds one to one to the class hierarchy (except where Smalltalk may play
tricks to keep the whole shebang working, like circular inheritance - but that's
another thread).  The metaclass hierarchy
determines class behavior (after all, classes can inherit too).

My point is not to confuse matters more, but to point out that you might
hear about the class/metaclass hierarchies, which is basically the same as the
instance/class sides.   As a concrete example, consider the method
truncate, which can be found on the instance side of Float (or in Float in the
class hierarchy).  Now consider the method pi, which can be found on the
class side of Float (or in Float class in the metaclass hierarchy).

====================================================================
Tom Gordon
IBM Software Solutions, IBM Smalltalk and VisualAge
"That's where I work, but I'm at home now, so the above is MY opinion, not IBM's"
"Use your computer - Use OS/2 Warp"



Mon, 02 Mar 1998 03:00:00 GMT  
 Class side vs Instance Side??

Quote:
>I am new to OO and I think I understand Classes and Instances.  What I don't
>understand is what is meant by Class side of the heirarchy and Instance side
>of the heirarchy. If instances are instantiated from classes why would not
>the heirarchy be the same?

One of the nice things about Smalltalk is that classes are objects, and
all properties of objects apply.  Essentially, classes have a duality of
behavior:
 1) behaving like a class - creating instances et cetera, where most of the
                             behaviour comes from the instance side of
                             Behavior, supplemented by specialized instantiation
                             'class' methods
 2) handling the common interests of a class of objects - the rest of the code
                             built on 'the class side'

If a classification of objects has 'state' that is common to all instances, this state
is maintained by the class object ( likely in class variables).  Any methods that
provide an interface to this state belong (and are restricted too) the 'class side'.

Where I usually start an arguement, is in my objection to the statement:
        "Behaviour common to all instances should be implemented in the
         class object"
You will often see constants coded on the class side with an abundence of instance
methods redirecting an instance query over to the class to retrieve a constant.
Since all instances share a common method dictionary, all methods in this dictionary
are common to all instances.  Therefore, I believe that such constants often should
be instance methods.

In summary, excepting the case where the class is used as a sole instance, the only
methods that belong in the class are:
 - instantiation methods, where parameters are required to instantiate a valid instance

 - methods that provide an interface to common class state (class variables)

Most Smalltalk code browsers allow you to switch between instance and class
side very easily.  Don't let this trick you into thinking that there is a special relationship
between an instance and its class.   Smalltalk just saves you the effort of adding
an instance variable to hold onto the class, in anticipation that there may be some
common state, and therefore an interface to that state.

David Brown
Opus Solutions
Toronto, Ontario



Fri, 06 Mar 1998 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Lines Side by Side?

2. smalltalk - java side by side

3. smalltalk - java side by side

4. Printing group footers side-by-side

5. Report details side by side

6. New MVS REXX Utility: Compare partitioned datasets side-by-side - pdsmatch.zip (1/1)

7. client side or server side scripting- new web user

8. Two text widgets side by side?

9. Tracks vs heads vs sides

10. SUnit class-side method suggestion

11. Nasty side-effect of using Dbhash class?

12. Server Side Includes .vs. TCL Source Speed

 

 
Powered by phpBB® Forum Software