[Biococoa-dev] Subclassing BCSequence really needed?

[Alexander Griekspoor]

Hi guys,

Although I most certainly applaud further improvements and 
reorganisations where necessary/possible, I agree with John primarily 
for the reason he already coupled to my name ;-) I guess there's 
something to say for both solutions, what Koen is proposing is the 
"bioJava" way. We have had previous discussions but right now I'm still 
in favour of the way things are setup right now, John has described my 
opinion pretty nicely as well.

> While we're engaging in a bit of redesigning suggestions, I have 
> problems
> with the BCSequence variables startPosition, endPosition, and range.  
> They
> don't reflect anything about the underlying sequence itself.  My
> understanding is that they are there for selection/display type usage.
I think we should think a bit of how to setup annotations and features, 
that's what these things should be in. Once that is in place, one can 
add as many start and stop positions as he/she wants. We can than get 
rid of these here.

> Given that, if we're trying to follow a MVC design, they belong in a
> sequence controller object rather than in the sequence itself.
Perhaps rather in a wrapper object (that if necessary a controller 
generates). This has been described in the discussions between Koen and 
me about restriction enzymes.

Cheers,
Alex

Ps. Today finally another milestone towards more programming time for 
BioCocoa, we have completed the story on the design award cube. It's 
now online on our website: http://www.mekentosj.com/goodies/cubism  
Enjoy!!



Op 23-okt-04 om 17:37 heeft John Timmer het volgende geschreven:

> Okay, once again, I feel compelled to point out that I'm arguing 
> strongly,
> but this is a case of trying to make a compelling case, rather than the
> annoyed sort of arguing.
>
>
>> One of the things that keeps bugging me for
>> instance is the duplicated code in BCNucleotideDNA and BCNucleotideRNA
>> for getting the subsequences.
> As I said the last time this came up, I put this together quickly, and 
> I
> intend to merge the common methods into an intervening class that's the
> common ancestor of DNA and RNA, both for the nucleotides and the 
> sequences.
>
> If what's bothering you so much are the two range methods, I can easily
> change the names and have them more explicitly parallel the superclass 
> -
> have the normal method just be the super's, and change the one that 
> handles
> ambiguity changed to _loose (right now, the range method overrides the
> super's to allow ambiguity, and the super's method is called by a 
> _strict
> method.  I'm sure that makes no sense, but I think I know what's 
> bothering
> Koen there) .  The key thing is that they're not as good as they can 
> be, but
> that doesn't mean there's a need to throw the whole structure out.
>
>
>> Somehow it doesn't seem the most
>> efficient approach, and also not applying the OOP paradigms.
> Collapsing a hierarchy of classes down to a single one isn't following 
> OOP
> paradigms, either.  The whole point of inheritance is to provide
> superclasses that hold common methods and subclass them to provide 
> specific
> functionality.  I think we've achieved that to a large extent.
>
> There's two other reasons I favor this structure:  What you tend to do 
> with
> DNA sequences and what you tend to do with protein sequences are 
> typically
> very different - I don't see why they all the differences should be 
> forced
> to reside in the same class.  The second is the thing that Alex always
> champions (and I sometimes argue against ;) - we should try to 
> represent
> every biological concept with an object, be it a codon, a sequence 
> fragment,
> whatever.  To make things more useful, it's better to force the code to
> reflect the biology, rather than distort the biology in order to have 
> it
> conform to how we want to code.
>
>
>> An addiitonal advantage of this approach is that when we think of a 
>> new
>> cool feature to add to BioCocoa, we only have to put it in a wrapper
>> class, instead of a slightly modified version in each of the 
>> subclasses
>> of BCSequence. This is much easier to maintain, and also less prone to
>> errors.
> Well, if it works for all sequences, it belongs in the superclass.  If 
> it
> doesn't it can go in the subclass.  I'm not sure what the wrapper adds 
> here
> or how it eliminates complexity.  If all it's doing is managing an 
> array of
> symbols, then it doesn't seem to be doing much more than NSArray is.
>
>
> While we're engaging in a bit of redesigning suggestions, I have 
> problems
> with the BCSequence variables startPosition, endPosition, and range.  
> They
> don't reflect anything about the underlying sequence itself.  My
> understanding is that they are there for selection/display type usage.
> Given that, if we're trying to follow a MVC design, they belong in a
> sequence controller object rather than in the sequence itself.
>
> Okay, back to my scheduled paper editing....
>
> Cheers,
>
> JT
>
> _______________________________________________
> This mind intentionally left blank
>
>
> _______________________________________________
> Biococoa-dev mailing list
> Biococoa-dev at bioinformatics.org
> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>
>
*********************************************************
                       ** Alexander Griekspoor **
*********************************************************
                 The Netherlands Cancer Institute
                 Department of Tumorbiology (H4)
           Plesmanlaan 121, 1066 CX, Amsterdam
                     Tel:  + 31 20 - 512 2023
                     Fax:  + 31 20 - 512 2029
                    AIM: mekentosj at mac.com
                     E-mail: a.griekspoor at nki.nl
                 Web: http://www.mekentosj.com

           LabAssistant - Get your life organized!
           http://www.mekentosj.com/labassistant

*********************************************************