[Biococoa-dev] Sequence factory

Charles PARNOT charles.parnot at stanford.edu
Thu Dec 23 18:48:03 EST 2004


Hi, it's me again :-)

OK, I have been looking at the code for a while, and I am now a 
fervent reader of the mailing list. It looks like the project is very 
active and quite exciting. I like most of the design choices that 
were made (regarding the 'debate', I have to say I like having 
BCSequence subclasses), and it looks like the Tools section is going 
in the right direction.

Now, there is still one thing that I dislike (arghh!), and this is 
really something that stroke me at the beginning, when I was looking 
at the header files, and looking at Biococoa from the perspective of 
a USER (so as a developer using BioCocoa, not a developer developing 
BioCocoa, I am sure you all see the big difference;-). In my short 
life as a programmer, I have mostly used Cocoa, and I am very used to 
the design patterns of the Apple's framework and of course, love 
them. If I was ever to develop an application based on BioCocoa, I 
would want to be able to type (or the same with BCSymbolList):
	mySeq=[BCSequence sequenceWithString:@"AGTAGATTTGAGGT"];

but I would hate to have to go through the doc and find out I have to 
do instead:
	factory=[BCSequenceFactory sharedSequenceFactory];
	mySeq=[factory sequenceWithString:@"AGTAGATTTGAGGT"];

Why do I need 2 classes? And I have to do this every time I use a 
sequence, which is going to happen very often? Why could not it work 
like NSString, NSNumber, or any other class, and have factory methods 
built into the class itself??

The reason that Koen advanced is that this allows to have all the 
code in one central location (to make the life of the BioCocoa 
developer easier.. but not necessarily the life of the developer 
using BioCocoa!). I think it does not need a separate class to get 
that separation. The superclass can easily take care of the all the 
factory methods, because it can return instances of the subclasses as 
necessary, so the code can be all in the superclass. In addition, the 
implementation can still be put in a separate file with the use of a 
category (the interfaces of the main implementation and of the 
category should however probably be combined in one header file so 
that it is easier to import all the methods at once). In fact, the 
code does not even need to be changed, except to replace the name 
BCSequenceFactory with the category BCSequence (BCSequenceFactory) 
and tweak the headers and imports.

In a way, BCSymbolList would look a little bit like a class cluster, 
except there is no need for a placeholder class (actually, this could 
also be implemented to automagically take care of -(id)initWithString 
when called on the superclass), and except some of the subclasses 
would be public (if somebody using BioCocoa wants to use more static 
typing and catch more problems at compile time).

I can elaborate more and give a possible implementation (which would 
mostly be some copy and paste), if  you don't already all hate me! In 
fact, some of your factory methods are inside the subclasses and 
could be all put in the proposed superclass category, like 
'dnaSequenceWithString:', etc... In a way, the factory code is thus 
already quite spread out (this would have to be in the TODO list 
anyway and could anyway be taken care of with the current design).

Remember this is just a comment of a BioCocoa newbie that may miss 
some of the subtleties... and well, I could still live with the 
current design!

Charles

-- 
Charles Parnot
charles.parnot at stanford.edu

Help science go fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford/

Room  B157 in Beckman Center
279, Campus Drive
Stanford University
Stanford, CA 94305 (USA)

Tel +1 650 725 7754
Fax +1 650 725 8021



More information about the Biococoa-dev mailing list