[Biococoa-dev] (no subject)

[Koen van der Drift]

On Jan 5, 2005, at 8:06 PM, Charles PARNOT wrote:

>>>
>>> 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 had a better look at your code, and see that you have actually most 
methods in BCSequence. Although I think most of them can actually go in 
the superclass of BCSequence, BCSymbolList.

so the class cluster should like:

BCSymbolList -> BCSequence -> BCSequenceDNA
						-> BCSequenceRNA
						-> BCSequenceProtein
						-> BCSequenceCodon

BCSymbolList is supposed to a 'barebone' sequence class, BCSequence has 
additional annotations.

>  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.

If the two methods are very different, then indeed it makes sense to 
have them in two different subclasses. My point before was that the 
methods in the various subclasses were almost identical, so there was 
no use in duplicating them.

>
>>
>>> 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 type.
>
> 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.

OK.


>
>
>>>
>>> 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'.
>

BTW, the reason that BioJava uses immutable sequences is: " It is worth 
noting that many BioJava implementations of Sequence and SymbolList do 
not allow edit operations as this may invalidate underlying Features or 
Annotations." That's indeed something to keep in the back of our minds.



- Koen.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 5290 bytes
Desc: not available
URL: <http://www.bioinformatics.org/pipermail/biococoa-dev/attachments/20050105/0e3b6474/attachment.bin>