[Biococoa-dev] Subclassing BCSequence really needed?

[John Timmer]

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