[Biococoa-dev] BCSequence class cluster

[Alexander Griekspoor]

Op 7-jan-05 om 23:20 heeft Charles PARNOT het volgende geschreven:

> First, if we go back again to the BCSequence, we have 2 options, 
> regardless of class cluster:
>
> * we only provide the user with one public class, either with a class 
> cluster or a general class that handle the different cases; how to 
> handle the irrelevant cases is debatable: bluntly (returning nil), 
> silently (returning self or empty objects or even [NSNull null]), with 
> a Biococoa-specific error reporting system (which could be useful 
> anyway at some point in the future), or with runtime errors (this 
> would not be very nice!)
I largely agree, but remember the latter isn't so bad at all as we're 
dealing with a different target audience here, yes runtime errors are 
bad if you ship programs to end users because nothing can be done at it 
anymore when the users experience the error (well, usually they won't 
even see it). Here users are developers who WILL notice the error while 
testing their app, and they will take them into account and change 
their code. But yes, it's a last resort.
>
> * you provide public headers for all the different types of sequence; 
> and you don't let the user get a sequence object BCSequence, without a 
> strong type, like you get with the method [BCSequence 
> sequenceWithString:aString]; so you provide the user with all the 
> objects BCSequenceDNA, BCSequenceRNA, BCSequenceCodon, 
> BCSequenceProtein, and the user chooses which one to use; this gives 
> more work to the user, but also more control and thus potentially more 
> flexibility (and BCSequenceNucleotide could fit in the picture too)
Hmm, this is not a good thing either, if you hand the user a bag of 
different sequence object and let him choose, than he (assuming that he 
knows what to choose) could have just as well send the proper method 
from the beginning right? I think such a method is supposed to figure 
out what the most likely type the handed sequence is of, and then 
return that one. Otherwise, the user should pick the right method.
>
> The choice depends on 2 things:
>
> * what the user wants; this is difficult; we are all potential users, 
> I suppose; maybe one hint is that the user of BioCocoa would also be a 
> user of Cocoa, and would be used to simple interfaces where she does 
> not have to handle the details and can get results in 2 lines of code
Yes please!
>
> * what the developers can do and how much work it requires; my feeling 
> is in both designs, there will have to be some compromises, and not 
> everything will be perfect; but it seems both options are feasible, 
> the class cluster potentially requiring more careful planning (but 
> once established, not more complicated than other approaches, or maybe 
> even simpler); the amount of code would be roughly equivalent in both 
> cases; the simple interface would make code maintainance easier (at 
> least in terms of testing) and would improve backward compatibility; 
> on the other hand, the more complex public interface would male our 
> life easier when we want to provide more radical extensions
Yes, I agree.
>
> Again, the reason why I came up with the idea of some public headers 
> for placeholder classes for typed sequences was to propose the user 
> BOTH OPTIONS! (but maybe we should not).
That's perhaps the most important question we have to answer first 
indeed.
>
> OK, so we have two choices for the interface. There might be ways to 
> provide both choices to the user, but we probably would not want to do 
> that as a first version and we have to choose anyway.
Right.
>
>
> Now, to go beyond the BCSequence implementation, you raise the issue 
> of the BCTools implementation. And it strikes me now that they are 
> very much interrelated and that there are other design issues with 
> BCTools and that they closely relate to BCSequence. We have now 
> another choice to make:
> * to perform an operation on a BCSequence, the user has to use one of 
> the BCTools; the simple BCTools might provide some convenience class 
> methods like
> 	+ (BCSequence *)complementForSequence:(BCSequence *)aSequence
> but more complex tools will be used by alloc/init and then settings 
> some parameters with some accessors methods and then calling a 
> 'result' method on the tool; the interface to the BCTools is public
> * to perform an operation on a BCSequence, the user has to use a 
> BCSequence method, such as 'complement', or 'cutWithEnzyme:' or 
> 'weigh' or ...; and the user does not even have to know that BCTools 
> exist!
Yes, that was my proposal, as expressed in the previous email, I would 
not like to force the user to continuously use tools. I don't care to 
use tools, but then the simple things should be hidden by convenience 
methods where we do the work.
>
> The latter gives a very simple interface, all within BCSequence. 
> However, while the concept of sequence is abstract enough to be put in 
> one class, I don't think the concept of tools or operation on a 
> sequence is simple enough to have all the interface all fit in the 
> context of BCSequence:
I think we all agree that somewhere there's a border we have to set on 
a per situation basis where to go for simple tools hidden by 
convenience methods and more complex situations where it would make 
sense not to hide things for the various reasons you have listed here.
>
> So my impression is that the BCTools interface will have to be public 
> to a certain extent (and for simple, obvious tools like translation, 
> some convenience methods will be included in the BCSequence interface, 
> the job being done really by a BCTool).
But I don't see why a method for which we provide a convenience method 
in BCSequence should be hidden in the BCTool, I don't mind that the 
BCTool methods we use internally in the BCSequence convenience methods 
are public as well, if a user wants to replicate the convenience method 
by hand for some reason, he's free to do so...

> Now, the user will have to provide the BCTool with a BCSequence. 
> Depending on the design chosen for BCSequence (one public class or 
> several typed subclasses), the interface for the BCTools will be quite 
> different, and the implementation as well:
>
> * with just one BCSequence, there is only the need for one 'init' 
> method, namely 'initWithSequence:'; the code may have to decide what 
> to do depending on the 'sequenceType' (the good thing is BCSequence 
> does not have to decide, so if a convenience method is provided in 
> BCSequence, it can be at the level of the superclass). So there might 
> be some 'if' and 'case' statement involved here. In certain cases, it 
> might get very difficult to stick to a simple general tool able to 
> handle all sequence types with just one class. Such an example is 
> alignement.
Hey, we can have the same approach we're now taking for bcsequence (are 
we? ;-) for such tools as well can't we? Have a public tool with 
private subclasses depending on the fed sequence subclass...

> A BCToolAlignement would be very different for a protein and a DNA. We 
> then may have to provide two tools in two separate classes and have 
> more stringent rules (the user will have to be more careful then), but 
> we don't have to give up the simplicity of the BCSequence, I think. 
> Anyway, alignements are really a very elaborate thing that may fall 
> out of the BCTool paradigm.
Hmm, that might no be the case actually, I've seen quite some alignment 
code recently and almost never people use different methods for 
aligning DNA and protein, there's really no big difference (take 
ClustalW for instance), only the scoring matrix might be a bit more 
complicated. A still think alignments are very nice in fact to be 
offered as a tool.

> *what you are saying, Peter (finally I comment on your comment!), is 
> that to solve these dilemna, we implement a class cluster together 
> with some typed classes that will be only used in certain tools;
>
> I did not mean to go that far in the discussion when I started that 
> email, but these issues will have to be debated, will have some impact 
> on the design of BCSequence,  and some design decisions will have to 
> be taken for the BCTools as well.
Yep.
>
Alex

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

Windows is a 32-bit patch to a 16-bit shell for an 8-bit
operating system, written for a 4-bit processor by a 2-
bit company without 1 bit of sense.

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