[Biococoa-dev] (no subject)
charles.parnot at stanford.edu
Wed Jan 5 20:06:24 EST 2005
>Some time now to reply :)
>For more info on class clusters, also checkout the page at CocoaDev:
>BTW, CocoaDev has a lot of very interesting pages.
This is how I get started a few months ago with my fitting program
where I decided to implement class clusters. It turned out to be
quite easy. Adding subclasses is easy too.
>>They would have some init methods, but when the user uses these
>>classes and alloc/init an instance, she would get in fact one of
>>the BCSequence subclasses. The compiler would not know and would
>>trust the headers to generate warning. For instance, the header for
>>the BCSequenceProtein placeholder class would not define the
>>methods 'complement' or 'cutWithRestrictionEnzyme:',
>Proteins can be digested as well, so I suggest we just use a general
>digest tool class. Just feed it a site where to cut, and the tool
>returns an array of locations, or subsequences.
This is EXCELLENT. The more general the approach, the more
encapsulated, the easier it will be to write and maintain and keep as
much backward-compatibility as possible.
>>No, there is no test at the beginning of a method. It is simply
>>coded in the subclass. For example, BCSequenceProtein could
>>override the 'complement' method to return an empty sequence.
>>Actually, this is not such a great example as 'complement' can
>>easily be taken care of by the superclass which would call
>>'complement' on the BCSymbol objects of the symbolArray.
>So, if I understand this correctly, when using class clusters, we
>still need to subclass each method? Not sure if I like that idea now
>:). As you remember, the reason I was trying to convince you guys to
>avoid subclassing, was to prevent code duplication in all the
>subclasses. This easily leads to errors and is difficult to
>maintain. I could of course be wrong, and not understand the class
>clusters completely yet.
OK, I should have been clearer. As much as possible, we should keep
the implementation in the superclass. And actually, 'complement' is
an excellent example of it and how the abstraction you have set up
for BCSymbol works well. When the case can be handled by the
superclass, we should do it. Most of the BCSequence methods in my
mini-project can be handled at the superclass level, I now appreciate
There might still be cases where specific methods have to be written
for a specific type of sequence. It is then easy to add the method to
the subclass, instead of having some case of if statements in the
superclass. This is more elegant and easier to maintain. I know you
already had the discussion with Alex. No matter what you do, if a
type of sequence has to be treated separately, you have to write two
different versions of a particular piece of code. It is actually
easier to separate the two cases in two separate methods for two
different classes in two different files. It still think I see your
point. The only problem with subclass is that it is quite easy not to
realize that you are duplicating code. It is more apparent when you
have a series of if statement in front of your eyes, all with the
same contents. You can also more easily spot the common stuff. Having
subclasses does not force you to duplicate code, it just tends to
happen more frequently.
>>Now I have an additional comment on what to do with strongly typed
>>instances, when the user is purposedly using a BCSequenceProtein,
>>has a call to 'complement' and ignores the compiler warning and
>>runs the program. It would then be nice to have run time error
>>(yeah, this is nice!) when calling a method on a strongly typed
>>instance. For this we could have an additional flag 'isTyped' and
>>have the private BCSeqProtein check the value of the flag in the
>>critical methods, and raise an exception if isTyped=YES or call
>>super if =NO.
>Again, maybe I don't understand the class clusters yet, but isn't
>the idea to have users only use BCSequence, not BCSequenceXXX? I
>agree with Alex about not using flags, though. We have introduced
>the BCSequenceType and BCSymbolSet (my preference) to identify the
Yes, sorry about the confusion. I was just proposing a possibility in
case the user complains she wants more strongly typed classes. I
agree it goes against the concept of class cluster and its
simplicity. I was just trying to show that even in the context of a
class cluster, there are ways to still propose some more strongly
typed headers without too much efforts, and give the option to the
user. It seems Alex and you don't really ask for that, and I like the
simplicity of just one public interface too. Let's just forget about
that or bring the issue back later.
>>To implement mutable objects in the class cluster could be a bit
>>tricky, because there are two conflicting subclass organizations
>>here: mutable/immutable and dna/rna/protein/codon. To get all the
>>combinations, it seems that we need 8 subclasses!!
>>Oops, Koen won't like this, LOL ;-) On the other hand, look at the
>>number of NSNumber subclasses...
>No, I don't like that :D, see my comment above. Another possibility
>(also stolen from BioJava) is to make a BCToolsEdit class that takes
>care of editing a immutable class.
I can see that: then BCToolEdit would havbe to return new instances
(otherwise it is not immutable anymore), but would deal with
optimization better than a dull 'copy'.
>>OK, I'll stop there, hoping teh europeans will get that before going to bed.
>Although European, I'm in North Carolina, so I have a few more
>hours. I will respond some more maybe later tonight.
Can't wait for more!!
charles.parnot at stanford.edu
Help science go fast forward:
Room B157 in Beckman Center
279, Campus Drive
Stanford, CA 94305 (USA)
Tel +1 650 725 7754
Fax +1 650 725 8021
More information about the Biococoa-dev