Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: methods or functions in oo programming
Message-ID: <4606@internal.Apple.COM>
Date: 9 Oct 89 20:51:50 GMT
References: <2616.252ca3bb@bmc.uu.se>
Sender: usenet@Apple.COM
Organization: Objects-R-Us,  Apple Computer, Inc.
Lines: 57

In article <2616.252ca3bb@bmc.uu.se> Mats.Sundvall@bmc.uu.se writes:

> and proteins. Shall I make the object molecule a child of CObject or
> make a new root?

It depends on whether you want your new object to have the behavior 
defined in CObject.  If an object-oriented system defines a root class 
(such as CObject), then it usually makes sense to inherit from that class. 
 

In MacApp, for example, there is a class TObject, which provides basic 
operations for all objects.  There is also a class TList that implements a 
dynamic array of TObject instances.  In this case, if you created a new 
class hierarchy, you couldn't put your objects in to a TList instance.  (I 
haven't looked at TCL to see if it is similar in this respect.)

There are starting to be some good papers on object-oriented design.  
Consult the proceedings of the OOPSLA conferences.

> Example: I want to be able to CUT a DNA with an enzyme. The result is
> one or many objects that contain part of the sequence. How do I get the
> resulting list of new DNA objects if I implement this as a method.

This sounds like it should be a method of DNA.  It is directly examining 
the state of the DNA object.  The method can create and return the new DNA 
objects.

In general, you should avoid examining the fields of an object from 
outside the object.

> The other method/function I want to implement is LIGATE. I pass LIGATE
> two objects of DNA and it assembles these into one object of DNA.
> Should this be a method or should it be a function.

This is less clear since the operation involves 2 DNA objects and neither 
is really dominant (although the ordering seems to matter).  If the 
operation modifies one of the original DNA objects, then it should 
definitely be a method.  Even if it doesn't this operation needs to access 
the internal state of the objects, and should still be a method.

There is an issue of how the method accesses the state of the second DNA 
object.  If it accesses the state directly, then it is assuming what the 
object's class will be.  Otherwise, it should call methods to access the 
object's state.

If the operation doesn't change either shape, then you could make it a 
plain routine.  Making it a method still provides a useful kind of 
scoping, both in terms of the C function names and in terms of the 
programmer's understanding.



Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1