[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