Mats.Sundvall@bmc.uu.se (10/06/89)
So, I bought TC 4.0 and jumed on the oo train. It looks really nice. The class library is very interesting. But when trying to write some code myself I think I kneed sopme basic advices. I have to implement an object that does not fit in the TC class tree. I want to implement an object tree that handles molecules like DNA, RNA and proteins. Shall I make the object molecule a child of CObject or make a new root? The when I have the object DNA that I want to be able to do things with the question is if the things I want to do shall be implemented as methods of the object or like functions that I pass the object to. 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. 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. Hopefully somebody can give me a hint so I can get together some code and ask you some more questions. Thanx, -- Mats Sundvall Biomedical Center +46/18174583 University of Uppsala Mats.Sundvall@BMC.UU.SE Sweden psi%24020019700620::MATS
lsr@Apple.COM (Larry Rosenstein) (10/10/89)
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
Mats.Sundvall@bmc.uu.se (10/10/89)
In article <4606@internal.Apple.COM>, lsr@Apple.COM (Larry Rosenstein) writes: > In article <2616.252ca3bb@bmc.uu.se> Mats.Sundvall@bmc.uu.se writes: > > 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 The problem I had to understand how to implement this "method" was that it takes two objects and you get one new object that is the sum of the two original objects. I guess I implement it as a method and pass the other object to the method. Then I have to dispose that object as it will not exist anymore. > 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 -- Mats Sundvall Biomedical Center +46/18174583 University of Uppsala Mats.Sundvall@BMC.UU.SE Sweden psi%24020019700620::MATS
lsr@Apple.COM (Larry Rosenstein) (10/11/89)
In article <2621.2531be57@bmc.uu.se> Mats.Sundvall@bmc.uu.se writes: > The problem I had to understand how to implement this "method" was that > it takes two objects and you get one new object that is the sum of the > two original objects. I guess I implement it as a method and pass the > other object to the method. Then I have to dispose that object as it > will not exist anymore. Since THINK C has no garbage collection, you have to adopt some conventions for memory management. It doesn't really matter if the operation is a standard function or a method, you still need to allocate a new object and worry about the old objects being combined. The latter seems to be a higher level issue. In other words, the code that calls the LIGATE method should also worry about what to do with the input objects. The other issue is whether the method should create the new object. The problem here is that the method has to choose the class of object to create and wire it into the code. One alternative is to pass a pointer to the "destination" object and have the LIGATE method fill it in. Alternatively, you can "clone" (no pun intended) one of the input objects so the result would be of the same class. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1